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Abstract 

This  thesis  presents  a  formaiized  framework  for  comparing  the  structure  and  se¬ 
mantics  of  softweire  architectures.  The  framework  uses  object  diagrams  for  aneJyzing  the 
structure  of  the  architectures  and  the  tixiomatic  approach  for  analyzing  the  semantics.  This 
framework  is  used  to  compare  the  Object  Connection  Update  (OCU)  model  (developed 
by  the  Software  Engineering  Institute)  against  four  other  software  eirchitectures:  VHDL 
defined  by  Lipsett,  MetaH  defined  by  Honeywell,  /iRapide  defined  by  Luckham,  aind  hier¬ 
archical  softw2ure  systems  as  defined  by  Batory.  The  gocil  of  the  comparison  was  to  evaluate 
the  OCU  model  for  suitability  within  prototype  application  composition  and  generation 
systems.  This  research  concluded  that  the  OCU  model  has  all  the  elements  necessary  for 
use  in  application  composition  aind  generation  systems.  Additionally,  the  framework  iden¬ 
tified  several  common  elements  in  all  the  software  architectures.  These  common  elements 
may  lead  to  the  development  of  a  “meta-model”  for  software  architectures. 
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Alternative  Architectures  for 


Domain-Oriented 

Application  Composition  and  Generation  Systems 


I.  Introduction  and  Problem  Statement 

1.1  Background 

Software  engineering  will  not  become  an  engineering  discipline  until  software  en¬ 
gineers  develop  software  systems  the  way  engineers  develop  systems.  Key  elements  of 
an  engineering  discipline  are  found  in  how  engineers  formulate  problems,  use  technology 
bases,  perform  design  by  composing  components  and  produce  solutions  (10).  The  most 
prominent  engineering  element  missing  from  software  engineering  is  the  extensive  amount 
of  reuse  from  a  technology  bzise.  Public  documentation  in  a  technology  base  is  reviewed  for 
possible  reusable  components  and  the  necesseiry  components  are  extracted  to  achieve  a  de¬ 
sign.  Engineers  also  have  a  way  of  measuring  the  success  of  the  design  before  construction 
actually  begins.  This  success  is  measured  by  employing  a  scientific,  theoretical  foundation 
to  verify  by  systematic  calculation  that  a  proposed  design  satisfies  the  specifications.  Once 
a  design  is  constructed  and  confidence  in  it  grows,  it  is  added  to  the  public  knowledge  baise 
for  futmre  reuse  (14).  This  is  how  engineering  has  sustained  its  level  of  development  over 
the  years. 

In  contrast,  software  engineers  currently  do  not  employ  techniques  relying  on  the 
composition  of  reusable  components,  a  published  knowledge  base,  or  methods  for  measuring 
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success  prior  to  development  (3).  By  starting  from  scratch  ezich  time,  a  software  engineer 
spends  extensive  amounts  of  time  debugging  the  whole  system.  If  the  analyst  had  employed 
reusability  (via  composition),  testing  would  be  reduced,  since  the  only  area  that  would 
need  to  be  tested  is  the  overadl  design  (given  that  the  individual  components  caime  from  a 
certified  technology  base).  This  would  preclude  testing  down  to  the  individu^J  component, 
since  the  component  came  from  a  knowledge  base  of  established  confidence.  Furthermore, 
if  the  analyst  used  formal  methods  as  a  means  of  verifying  the  overall  system  design  (by 
use  of  proofs),  confidence  in  the  system  could  be  established  prior  to  system  development. 

As  mentioned  above,  engineers  reuse  components.  These  components  are  nothing 
more  than  models.  Models  can  be  thought  of  as  a  codified  body  of  scientific  knowledge 
and  technology  presented  in  a  (re)usable  form  (10).  As  such,  models  have  a  way  to 
influence  or  interf2ice  with  their  environment.  Thus,  models  are  merely  representations  of 
real  world  objects.  These  models  are  what  an  engineer  extracts  firom  a  public  knowledge 
base  to  aid  in  design.  At  present,  software  engineers  are  just  discovering  the  eulvEintages  of 
reuse  by  employing  object-oriented  madysis  and  design.  It  has  been  shown  that  software 
developed  using  the  object-oriented  methodology  has  very  high  cohesion  within  the  object 
(12).  Further,  these  systems  demonstrate  very  loose  coupling  between  the  objects  (12). 
The  loose  coupling  of  the  objects  and  high  cohesion  within  an  object  have  made  it  easier 
to  reuse  softwaure  components. 

Peirt  of  designing  a  software  system  requires  an  analysis  of  the  domain  of  the  problem 
space  by  the  software  engineer.  Prior  to  systems  analysis,  the  software  engineer  creates  a 
model  of  the  softwzire  system,  trying  to  generalize  all  subsystems  in  the  application  domeun 
by  means  of  a  domain  model  that  transcends  specific  applications.  If  this  is  successful. 
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the  next  step  is  to  define  a  domain-specific  language.  This  leinguage  becomes  the  model 
and  is  used  to  describe  objects  and  operations  common  to  that  domain.  A  more  formal 
definition  would  be  “a  language  with  syntax  and  semantics  designed  to  represent  all  valid 
actions  and  objects  in  a  pairticular  domain”  (19). 

Dming  system  design,  the  software  engineer  chooses  a  software  architecture  that 
logically  follows  from  the  domain  model.  Webster’s  dictionary  defines  architectiure  as  “a 
method  or  style  of  building.”  To  apply  this  definition  to  a  software  system  would  imply 
“the  way  objects  (models)  are  composed  is  defined  by  an  architecture.”  Another  way  to 
define  software  architecture  is  that  a  software  architecture  imposes  a  uniform  style  on  the 
structure  of  the  software  system  (1:110).  A  software  architecture  is  a  selection  (from  a 
technology  base/pubUc  knowledge  base)  of  models  and  composition  rules  that  defines  the 
structure,  performamce,  and  use  of  a  system  relative  to  a  set  of  engineering  goals  (14:8). 
Thus,  an  architecture  is  a  way  of  composing  models,  using  engineering  practices  to  achieve 
an  overall  system  design. 

While  the  software  architecture  serves  eis  the  framework  for  the  design,  this  concept 
is  insufficient  by  itself  for  supplying  the  additional  deteuls  required  for  a  specific  design. 
Additional  domain  knowledge  is  still  needed  to  instantiate  components  of  the  architecture 
and  develop  optimized  Eilgorithms  for  the  problem  domeiin.  These  details  may  be  provided 
by  use  of  the  domain-specific  language.  Thus,  the  general  concept  of  a  software  architecture 
and  the  specific  design  deteiils  provided  by  domain-specific  languages  axe  combined  to  create 
what  can  be  termed  a  domain-specific  softwEure  architecture  (DSSA)  (5). 
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So,  vintil  software  engineers  employ  extensive  reuse  of  -oftware  components  (such 
as  models  or  objects),  incorporate  a  means  of  verifying  a  design  prior  to  implementation 
(formal  methods),  cind  establish  a  software  architecture  that  easily  incorporates  reusable 
components,  they  will  continue  to  produce  software  systems  with  large  zunounts  of  errors. 
These  systems  will  continue  to  tzdce  a  large  amount  of  resources  during  development  and 
may  or  may  not  meet  user  requirements. 

1.2  Problem 

To  help  push  software  engineering  into  more  of  a  true  engineering  discipline,  the  Air 
Force  Institute  of  Technology  (AFIT)  has  prototyped  a  dommn-oriented  application  com¬ 
position  and  generation  system  called  Architect.  It  is  based  on  integrating  the  concepts 
of  software  architectures  and  formal  domain  models.  The  purpose  of  Architect  is  to  allow 
an  application  specialist  to  input  system  specifications  in  a  domeiin-specific  language.  Ap¬ 
plication  specialists  are  sophisticated  “users”;  they  are  familiar  with  the  overall  domain 
and  tmderstand  what  the  new  application  must  do  to  meet  requirements;  they  provide  the 
application-specific  information  needed  to  specify  an  application  (20:3-2).  After  verifying 
that  the  new  composition  behavior  meets  the  specifications,  application  specialists  can 
have  Architect  synthesize  the  appropriate  implementation  of  the  specification.  Synthesiz¬ 
ing  a  specification  is  the  transforming  of  the  specification  into  the  language  of  the  target 
system. 

At  the  center  of  Architect  is  a  technology  base  used  to  store  domain  zmd  software 
engineering  information.  This  technology  base  consists  of  formEil  specifications  developed 
using  the  Refine  formal  specification  language.  The  softwai-e  architecture  of  Architect  hais 
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been  implemented  using  the  Object  Connection  Update  model  proposed  by  the  Software 
Engineering  Institute  (SEI)  (14).  Architect’s  initial  implementation  did  not  incorporate 
all  of  the  OCU  methodology.  One  of  the  focuses  of  this  thesis  effort  is  on  £idding  additional 
functionality  to  Architect.  Architect’s  new  functionality  and  corresponding  implementa¬ 
tion  details  eire  presented  in  subsequent  chapters. 

Another  focus  of  this  research  is  on  the  suitability  of  the  OCU  model  for  the  software 
architectmre  of  Architect.  The  software  architectural  model  within  Architect  must  be 
flexible  enough  to  allow  for  future  enhancements,  as  well  as  provide  the  capability  to 
accommodate  a  technology  base  with  components  from  different  domains.  To  aid  in  the 
establishment  of  the  technology  base,  Architect  should  allow  for  the  inclusion  of  artifacts 
from  other  domains.  However,  prior  to  allowing  artifacts  from  other  domains,  a  mapping 
between  software  architectures  used  in  different  domains  must  be  established.  The  first 
step  in  developing  a  mapping  between  softweire  architectures  is  to  establish  a  f^^unework 
for  comparing  softweire  zurchitectures. 

1.2.1  Problem  Statement. 

Develop  a  formalized  model  which  serves  as  a  framework  for  comparing  software 
architectures.  Include  in  this  framework  a  consistent  standard  for  analyzing 
software  architectural  structures  and  analyzing  the  semantics  of  the  architec¬ 
tural  components. 

1.3  Scope 

The  scope  of  this  research  includes  the  development  of  a  standard  framework  for 
comparing  software  eirchitectures  beised  on: 
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1.  Object  Diagreuns,  as  presented  by  Rumbaugh  (22),  as  the  representation  for  com¬ 
paring  structured  components  of  an  architecture.  I  will  not  specify  complete  object 
models  with  methods  and  attributes  per  (22),  as  the  focus  of  this  thesis  is  on  archi¬ 
tectural  entities  and  their  relationships. 

2.  An  axiomatic  approach  compeuring  the  semantics  of  the  components  that  appear 
similar  between  architectures  (4,  11).  Additionally,  the  semantic  analysis  of  the  ar¬ 
chitectural  components  is  limited  to  identifying  the  preconditions  and  postconditions 
that  must  be  maintained  as  some  abstract  program  is  executed.  The  development  of 
a  standardized  abstract  program  language  and  corresponding  execution  function  is 
left  for  future  research. 

This  thesis  also  includes  the  implementation  of  an  event-driven  simulation  capability 
within  the  Architect  prototype.  More  specifically,  I  address  the  changes  that  need  to  be 
made  to  the  OCU  architectural  model  and  its  simulation  capabilities  within  Architect 
to  support  an  event-driven  mode  of  execution.  These  cheinges  are  limited  to  identifying 
structural  chzmges  to  the  subsystems  and  primitives,  as  well  as  the  execution  capabilities  of 
the  subsystems  and  the  primitives  within  Architect.  It  does  not  include  the  development 
of  an  application  executive,  as  that  is  addressed  in  a  separate  effort  (29).  In  essence,  the 
application  executive  p’r.  i^es  an  operating  system  type  environment  with  services. 

1.4  Big  Picture 

Figure  1.1  shows  the  overall  research  effort  that  is  being  conducted  at  AFIT.  My 
particular  area  of  reseeirch  is  isolated  to  the  Application  Composer  block  in  the  lower  left 
hand  comer. 
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Figtire  1.1  Architect’s  Software  Composition  and  Generation  Toolset 
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1.5  Sequence  of  Presentation 


The  order  of  presentation  for  the  rest  of  this  thesis  is  sis  follows.  Chapter  II  provides 
some  example  definitions  for  a  software  architecture.  It  also  presents  some  identifiable  soft¬ 
ware  architectures  used  in  industry  today.  Chapter  III  details  requirements  for  comparison 
of  software  architectures,  as  well  as  the  concept  of  operations  for  an  event-driven  simulation 
capability  within  Architect.  Chapters  IV  and  V  present  the  methodology  for  comparing 
the  alternative  software  architectures  and  the  results  of  employing  this  methodology  on 
the  five  architectiures.  Chapter  VI  provides  detailed  design  of  the  event-driven  capability 
within  Architect,  while  Chapter  VII  shows  how  the  event-driven  capability  was  validated. 
Finally,  the  results  and  conclusions  for  this  research  effort  are  presented  in  Chapter  VIII. 
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II.  Literature  Search 


2.1  Introduction 

The  previous  chapter  presented  Webster’s  definition  of  architecture  as:  “a  method 
or  style  of  building" .  Also  presented  were  severad  definitions  for  software  eurchitecture.  In 
this  thesis,  a  software  architecture  will  be  defined  as  “...a  selection  (from  a  technology 
beise/public  knowledge  base)  of  models  and  composition  rules  that  defines  the  structiure, 
performance,  and  use  of  a  system  relative  to  a  set  of  engineering  goals”  (4).  In  this  chap¬ 
ter,  I  examine  some  identifiable  software  architectures.  Next,  I  discuss  Domain-Specific 
Software  Architecture  and  define  all  the  terms  associated  with  this  architectural  model. 
Finally,  I  provide  examples  of  the  use  of  some  of  the  different  software  architectures. 

2.2  Software  Architectures 

The  following  sections  present  a  description  of  some  of  the  common  software  archi¬ 
tectures  used  in  system  design. 

2,2.1  Layered  Architecture.  Software  designed  as  an  hierarchical  collection  of 
components  is  a  layered  architectme;  each  level  of  the  software  is  built  using  the  software 
components  from  a  lower  layer.  Ideally,  components  at  each  layer  are  independent  of  each 
other.  Figure  2.1  presents  a  conceptual  model  of  a  layered  eirchitecture.  The  communi¬ 
cation  in  a  layered  architectvure  is  one-way;  that  is,  the  components  only  know  about  the 
layers  below  and  communicate  with  only  those  lower  modules;  they  have  no  knowledge 
of  what  is  in  the  layers  above  (22:200)(23:72).  Examples  of  a  layered  eirchitecture  eire 
operating  systems  and  data  base  management  systems. 
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Useful  Systems 


Basic  Utility 


Users 


Figure  2.1  Layered  Sy8tem8(3) 


2.2.2  Batch  Transformation  or  Pipe  Architecture.  A  batch  transformation  ar¬ 
chitecture  is  a  sequential  input-to-output  process,  in  which  inputs  are  supplied  at  the 
beginning  of  the  pipe  and  outputs  are  presented  at  the  other  end  of  the  pipe.  Figure  2.2 
presents  a  batch  transformation  architecture.  The  architecture  is  broken  down  into  stages 
where  each  stage  performs  one  part  of  the  transformation  on  the  input  data.  Each  stage 
only  knows  about  the  stages  immediately  preceding  it  and  following  it,  as  well  as  the  in¬ 
puts  and  outputs  associated  with  its  particular  stage.  There  are  no  interactions  with  the 
outside  world  once  the  transformation  starts  (22:212). 
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2.2.3  Real-Time  Architectures.  A  real-time  circhitecture  is  used  when  the  timing 
and  performance  criteria  of  a  particular  system  are  considered  essential  to  the  design;  i.e., 
for  any  critical  actions  that  the  software  must  perform,  the  action  must  be  done  in  an 
absolute  interval  of  time.  Real-time  architectures  are  usually  complex  and  involve  inter¬ 
rupt  handling,  prioritizing  tasks,  and  coordinating  resources  among  multiple  processors. 
Subsequently,  their  software  is  often  non-logic2illy  structured  (22:216).  An  example  of  a 
rejd-time  system  is  a  flight  control  system  on  any  aircraft. 

2.2.4  Object-Oriented  Architecture.  An  object-oriented  architecture  contains 
models  which  encapsulate  both  data  and  behavior  into  a  single  entity  (22:1).  Models  within 
an  object-oriented  architecture  are  representations  of  real  world  entities.  Each  model  or 
object  contains  attributes  and  operations;  the  attributes  contain  the  state  information  of 
the  object,  while  the  operations  are  used  to  change  the  state  of  the  object.  An  object- 
oriented  architecture  consists  of  objects  changing  the  state  of  other  objects  by  invoking 
the  other’s  operations  via  message  pzissing. 

2.2.5  Production  System  or  Rule-Based  Architecture.  A  production  system  or 
rule-based  architecture  consists  of  a  set  of  rules,  a  knowledge  base,  a  control  strategy,  and 
a  rule  applier.  Figure  2.3  is  a  graphical  representation  of  a  rule-based  system.  The  set  of 
rules  provide  a  description  of  the  operation  to  perform  when  a  particular  rule  is  applied. 
The  knowledge  base  conteiins  information  applicable  to  the  task  at  hand.  The  control 
strategy  specifles  the  order  in  which  the  rules  are  compared  to  the  data,  and  it  has  a  way 
of  deconflicting  rules  when  multiple  rules  can  be  applied.  Finally,  the  rule  applier  applies 
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the  rule  selected  ob  specified  by  the  control  strategy  (21:36).  An  example  of  a  rule-based 


system  is  a  hospital’s  diagnostic  station. 


Knowledge  Base 


Figure  2.3  Rule-Based  Systems(3) 


2,2.6  Blackboard  Architecture.  A  blackboard  architecture  consists  of  knowledge 
sources,  a  blackbozurd,  aind  a  control  system.  The  knowledge  sources  (ks)  are  a  set  of  inde¬ 
pendent  modules  that  contmn  the  system’s  domain-specific  information.  The  blackboard 
is  a  sheared  data  structure  through  which  the  knowledge  sources  communicate  with  each 
other  (see  Figure  2.4).  Finally,  the  control  structure  determines  which  knowledge  source 
has  access  to  the  blackboard  to  perform  some  operations  or  communications.  A  blackboeurd 
eurchitecture  operates  by  allowing  the  knowledge  sources  to  post  items  on  the  blackboard, 
reawi  items  from  the  blackboard,  or  act  upon  messages  posted  on  the  blackboard  (21:439). 

2.3  Software  Architectures  Versus  Object-Oriented  Design 

Software  architectures  have  been  defined  as  a  style  of  composing  software  compo¬ 
nents;  this  should  not  be  confused  with  the  term  object-oriented  architecture.  Object- 


2-4 


Figure  2.4  Blackboard  System(3) 


oriented  architecture  allows  the  software  system  designer  to  “abstract-out”  components  of 
a  softwaure  architecture;  this  abstraction  then  allows  the  system  developer  to  focus  on  the 
high-level  design  issues  (22).  The  use  of  an  object-oriented  design  in  tbe  development  of 
a  system’s  software  architecture  allows  the  components  of  the  ardiiiecture  to  be  loosely 
coupled,  while  providing  a  high  level  of  cohesion  within  the  component.  The  loose  coupling 
eind  high  cohesion  is  achieved  through  the  encapsulation  of  the  behavior  and  data  structure 
in  the  software  (22:1).  To  use  the  pipe  architecture  as  an  example,  the  pipes  or  filters  can 
be  designed  as  separate  entities  or  objects  imder  the  object-oriented  paradigm.  Data  is 
passed  between  the  filters  as  previously  shown  in  Figure  2.2,  but  eeich  filter  performs  its 
operations  on  the  data  by  having  one  of  its  methods  invoked.  This  does  not  violate  any 
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principles  of  a  filtering  aurchitectiure;  that  being  each  stage  knowing  only  of  its  predecessor 
and  its  successor. 

2.^  Domain- Specific  Software  Architectures  (DSSA) 

Before  a  good  definition  of  DSSA  can  be  given,  some  additional  background  termi¬ 
nology  is  needed  to  complete  an  understanding  of  DSSA,  as  well  as  distinguish  DSSA  from 
other  software  architectures. 

The  first  term  that  needs  to  be  understood  is  “model”.  A  model,  as  presented  in 
Section  1.1,  is  a  codified  body  of  knowledge  in  reusable  form  (10).  This  implies  that  there 
are  some  standard  interfaces  for  communicating  with  and  controlling  this  model.  Once  the 
interfaces  are  standardized,  this  model  is  a  semi-autonomous  set  of  code  that  can  be  used 
in  the  composition  of  larger  systems.  In  other  words,  the  model  is  reusable. 

The  important  aspect  of  a  model  is  its  codified  body  of  knowledge.  This  knowledge 
represents  the  information  needed  to  accomplish  its  behavior.  Most  of  the  information  is 
loced  to  the  model;  other  information  may  have  to  be  imported  via  the  communication 
interf2ice  (14). 

Models  are  the  basis  for  DSSAs.  The  next  step  in  understmding  a  DSSA  is  to 
understand  what  is  memt  by  domain  ^m^llysis  md  domain-specific  language.  Domain 
analysis  is  the  generalization  of  a  problem  area,  where  a  problem  area  is  a  narrow  area  of 
interest.  Prieto-Diaz  defines  domain  analysis  as  the  process  used  to  identify,  capture,  and 
orgmize  information  in  a  dommn  of  interest  (19:47-48).  As  a  result  of  domain  malysis. 
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certain  entities  become  evident  within  the  problem  area.  These  entities  evolve  into  models, 
which  are  used  in  the  subsequent  development  of  the  system. 

A  domain-specific  language  is  developed  as  part  of  a  domain  anailysis.  The  enti¬ 
ties/models  formalized  from  the  dom«dn  analysis  become  part  of  the  dommn-specific  lan¬ 
guage.  The  domain-specific  language  includes  any  operations,  actions  or  communications 
between  the  models  of  the  problem  2u-ea. 

A  DSSA  includes  a  software  zirchitecture  (drawn  from  the  domain  analysis),  domain 
models,  a  domain-specific  language,  and  software  engineering  knowledge  (18).  A  DSSA 
defines  a  way  of  composing  dommn  models,  using  a  set  software  architecture  to  solve  a 
family  of  related  software  problems  (18).  The  domain-specific  language  defines  the  actions 
and  operations  of  the  domain  models  within  the  DSSA.  Finally,  the  software  engineering 
knowledge  is  captured  in  both  the  software  architecture  and  the  domain  models  within  the 
system. 

Lowry  defines  an  eurchitecture  as  a  high  level  description  of  a  generic  type  of  softw^^^e 
system:  “it  includes  functional  roles  of  major  software  components  and  their  interrela¬ 
tionships  stated  in  an  application  oriented  language  for  use  in  reasoning  and  composing 
prototype  components”  (16).  The  preceding  sentence  describes,  in  a  general  sense,  an 
application  composition  and  generation  system,  which  is  a  transformation  system  for  a 
problem  domain  or  space  (16).  Further,  a  treinsformation  system  is  a  combination  of  spe¬ 
cialized  components  and  software  engineering  knowledge  so  that  the  software  is  developed, 
modified,  and  maintmned  at  the  specification  level  and  automatically  transformed  to  im- 
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plementation  or  target  code  (16).  This  explicitly  describes  Architect,  which  is  a  ongoing 
research  eflfbrt  (3,  28,  20). 

2.5  Example  Systems  and  Their  Software  Architectures 

The  following  are  some  software  architectures  currently  being  employed  or  defined 
by  the  software  industry  today. 

2.5.1  DSSA  for  Intelligent  Guidance,  Navigation  and  Control.  Honeywell  and 
the  University  of  Maryland  are  currently  developing  a  software  architecture  for  intelligent 
(adaptive)  guidance,  navigation  and  control  (1).  They  are  proposing  a  layered  architecture 
with  tools  to  support  the  different  layers  within  the  architecture.  Their  architecture  will 
be  amenable  to  automatic  zmalysis,  configuration,  and  population  with  very  heavy  reliance 
on  formal  methods.  Ultimately,  they  aie  striving  for  formal  verification  in-the-large  which 
will  lead  to  improvements  in  over<ill  qu^llity  in  the  system  being  developed.  The  user  will 
specify  somce  modules  to  be  included  in  a  system,  how  these  modules  are  to  be  scheduled, 
and  how  these  modules  are  to  communicate.  The  tool  set  performs  the  haurd  real-time 
scheduling,  sensitivity  ansdysis,  timing,  data,  reliability  analysis  and  then  automatically 
assembles  the  modules  into  the  final  system,  generating  all  necessary  code. 

2.5.2  DSSA  for  Avionics  System.  IBM,  along  with  researchers  from  MIT,  Cor¬ 
nell,  the  University  of  Texas  at  Austin,  and  the  University  of  California  at  Irvine,  is  striving 
to  create  a  workstation-based  environment  to  support  the  development,  maintenance  and 
upgrade  of  avionics  systems  with  an  order-of-magnitude  improvement  in  quality  and  pro¬ 
ductivity  over  cmrent  approaches  through  the  reuse  of  laurge  portions  of  well-designed  and 


2-8 


documented  softw^^:e  (8).  Any  system  for  navigation,  guidance,  and  flight  director  must 
manage  the  routing  of  source  data  from  suppliers  to  consumers  with  minimum  handling 
of  this  data  to  prevent  “data  aging”.  Their  approach  to  DSSA  is  to  use  constraint-based 
reasoning  tools  to  guide  the  user,  using  domain-specific  terms,  in  selecting  adaptation  val¬ 
ues  for  the  system  under  development.  The  models  are  automatically  aussembled  into  an 
executable  prototype,  which  may  be  run  to  examine  the  system  behavior.  IBM  proposes 
doing  a  domedn  analysis  of  the  problem  space  to  identify  common  concepts.  The  concepts 
to  be  modeled  will  have  well  defined  interfaces  and  will  include  flexible  combination  mech- 
einisms.  IBM  believes  that  these  formal  interfaces  will  characterize  the  semantics  of  each 
model(behavior),  entry  and  exit  constraints,  performance  and  timing  constraints,  depen¬ 
dency  constraints  (layering),  and  sequencing.  Since  the  architecture  is  set  amd  provides  a 
structure  or  solution  for  a  class  of  problems,  the  analyst  can  select  and  adapt  these  models 
for  the  task  at  hand  using  the  defined  zirchitecture. 

2.5.3  VHDL.  VHDL  (VHSIC  (Very  High  Speed  Integrated  Circuit)  Hardware 
Description  Language)  was  designed  by  the  U.  S.  government  to  standardize  the  VLSI 
(Very  Large  Scale  Integration)  chip  design  process  euid  manage  the  leirge  volumes  of  data 
needed  in  designing  a  new  circuit.  VHDL  is  a  standeirdized  design  and  description  language 
that  integrates  three  different  models  into  one.  These  interdependent  design  models  are  the 
behavioral  model,  timing  model,  emd  the  structural  model.  VHDL  has  been  designed  such 
that  the  structural  model  eind  behavioreil  model  can  be  intertwined  where  their  individual 
boundaries  are  blurred  within  an  application,  or  the  structural  model  and  behavioral  model 
can  be  distinct  and  separate  entities  within  an  application.  The  smallest  executable  artifact 


2-9 


in  VHDL  is  an  Entity.  An  Entity  takes  signals  and  internal  attributes  and  generates  new 
signals.  Similarly,  since  an  entity  may  consist  of  components,  further  transformations  of 
in-signads  are  possible  (15). 

2.5.4  fiRapide.  pRapide  is  an  executable  architecture  definition  language  in¬ 
tended  primarily  for  defining  time-sensitive  concurrent  systems.  This  language  is  derived 
as  a  subset  of  the  Rapide-1  prototyping  language  which  contains  object-oriented  fea¬ 
tures  aind  reactive  programming  constructs.  /^Rapide  is  an  event  processing  language, 
where  events  are  tuples  of  information.  The  information  in  an  event  may  include:  orig¬ 
inator,  consumer,  time,  activity  to  do,  activity  done,  data  values,  etc.  The  semantics  of 
/xRapide  are  based  on  event  processing;  that  is,  generating  events,  sending  events,  receiv¬ 
ing  events,  and  deciphering  events.  The  authors  of  /ixRapide  believe  this  to  be  the  most 
general  way  to  model  communications  between  components  that  are  computing  indepen¬ 
dently.  Subsequently,  synchronous  and  serial  communications  can  be  modelled  in  terms  of 
event  processing  as  well  (17). 

2.5.5  OCU.  The  software  ^lrchitecture  used  by  Architect  for  modeling  a  system’s 
behavior,  is  the  Software  Engineering  Institute’s  (SEI)  Object  Connection  Update  (OCU) 
(14).  The  major  component  or  level  of  abstraction  within  the  OCU  model  is  the  subsystem. 
A  subsystem  consists  of  objects,  an  import  area,  an  export  area,  and  a  controller.  The 
controller  is  a  self-contmned  unit;  it  is  the  locus  of  the  mission.  Subsequently,  the  objects 
within  the  subsystem  provide  the  state  of  the  subsystem.  The  controller  of  a  subsystem  is 
only  awEire  of  subordinate  objects  for  which  it  has  control  over;  it  is  unaware  of  any  other 
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superior  or  sibling  subsystems.  The  only  interface  a  subsystem  has  with  its  environment 
is  through  the  import  and  export  ^lreas. 

Due  to  the  way  the  SEI  has  defined  objects  within  the  OCU  model  (with  standard¬ 
ized  interfaces  and  operations  performed  by  the  objects),  objects  and  subsystems  can  be 
composed  almost  arbitrarily.  The  architecture  does  not  impose  any  constraints  on  object 
or  subsystem  composition  as  long  as  the  data  interfaces  to  these  components  cire  standard¬ 
ized. 

The  highest  level  of  abstrziction  within  the  OCU  model  is  the  Application  Executive. 
The  Application  Executive  controls  subsystem  activities  and  scheduling. 

2.5.6  Conclusion.  My  research  revolves  around  enhancing  the  Architect  proto¬ 
type  application  composition  and  generation  system  as  defined  by  (16).  All  the  software 
architecture  projects  presented  in  Section  2.5  of  this  chapter  are  teurgeting  their  software 
for  a  particuleir  application  zind  domaun.  At  AFIT,  the  research  is  focused  on  developing 
an  application  composition  and  generation  capability  that  transcends  many  domains.  My 
particulcir  research  is  focused  on  imcovering  commonalities  between  software  aurchitectures 
by  identifying  a  suitable  freunework  for  comparing  different  architectures.  The  common¬ 
alities  among  architectures  should  eventually  lead  to  more  than  just  code  reuse,  it  could 
lead  to  design  reuse.  Design  reuse  is  the  reuse  of  the  knowledge  that  went  into  designing 
a  software  system  or  smaller  component  (architectursd  fragment)  of  the  system. 

The  initial  implementation  of  the  OCU  model  in  Architect  has  the  domain-specific 
information  of  the  problem  space  captured  at  the  primitive  level.  Most  of  the  higher-level 
design  information  has  been  captured  in  the  software  architectural  model,  OCU.  As  such. 
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the  present  software  architecture  in  Architect  does  not  directly  incorporate  domain-specific 
information.  This  provides  Architect  with  the  capability  to  cross  domain  boimdaries. 


I 


I 
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III.  Evaluation  of  Architect’s  Software  Architecture 

3.1  Introduction 

Architect  is  a  prototype  implementation  of  an  application  composition  and  genera¬ 
tion  system;  as  a  result,  there  are  certain  aspects  that  still  need  to  be  investigated  and 
incorporated  into  Architect.  This  research  effort  focuses  on  identifying  any  swlditional 
software  architectural  components  required  to  support  the  OCU  concept  of  an  Application 
Executive,  comparing  the  OCU  software  architecture  against  other  software  architectures, 
as  well  as  implementing  several  already  defined  enhancements. 

3.1.1  Background.  The  initial  implementation  of  Architect  by  Anderson,  Ran- 
dour,  and  Weide  (3,  20,  28)  produced  a  limited  capability  application  composition  and 
generation  system.  For  example.  Architect  could  only  simulate  models  that  exhibited  a 
sequential  mode  of  behavior  (as  defined  by  a  subsystem’s  Update  algorithm).  Addition¬ 
ally,  the  system  was  validated  using  only  two  domains,  one  pedagogical  and  the  other  logic 
circuits,  neither  of  which  exhibit  any  complex  behaviors  such  as  feedbeick. 

3.1.2  Current  Research  Issues. 

1.  Application  Executive;  More  research  is  needed  to  define  the  application  executive 
role  of  an  application  composition  and  generation  system.  Welgan  is  presently  defin¬ 
ing  a  domain  model  for  an  application  executive  (29).  As  part  of  his  domain  model 
validation,  the  application  executive  within  Architect  will  be  implemented  based  on 
the  OCU  model.  The  application  executive  will  be  a  collection  of  objects  composed 
into  a  subsystem  that  provide  executive  services  to  the  application  being  modelled. 


An  additional  requirement  identified  by  previous  researchers  was  the  incorporation 
of  different  modes  for  simulating  an  application’s  behavior.  The  additional  modes  of 
execution  all  incorporate  the  processing  and  management  of  events.  These  different 
modes  of  execution  are  addressed  in  (29);  however,  defining  the  structure  of  events, 
along  with  their  processing  and  management  within  subsystems  and  primitives  is 
eiccomplished  in  this  thesis. 

2.  Incorporation  of  Additional  Domains:  Additional  domains  also  need  to  be  modelled. 
Waggoner  and  Warner  are  populating  Architect’s  technology  base  with  new  domains; 
the  new  domains  are  missile  guidance  components  and  digital  signal  processing  com¬ 
ponents,  respectively  (26,  27).  Furthermore,  Waggoner  is  also  implementing  a  time 
delay  to  the  initial  digital  circuits  domain  (26). 

3.2  Review  of  Alternative  Architectures 

To  evaluate  the  OCU  uchitectural  model,  other  architectiures  were  reviewed  and 
analyzed.  The  architectures  are  either  in  use  today  as  a  fully  functioned  software  set  or 
are  being  developed.  The  software  architectures  reviewed  were  VHDL  (15),  MetaH  (25), 
/zRapide  (17)  and  IBM  ADAGE  (8,  6). 

3.2.1  Determine  a  Common  Framework.  As  part  of  the  compeurison  of  the  alter¬ 
native  architectures  to  the  OCU  model,  a  framework  was  needed  that  would  adequately 
describe  2dl  five  of  the  architectures.  Identifying  a  common  frzunework  for  comparing  ar¬ 
chitectures  is  recommended  by  Allen  and  Garlem  in  (2:1).  This  framework  needs  to  allow 
for  the  structural  analysis  of  each  software  architecture,  as  well  as  the  comparison  of  the 
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behavior  of  each  of  the  architectural  components  within  an  architecture  and  among  archi- 
tectmes.  The  framework  developed  during  this  research  is  presented  in  Chapter  IV. 

5.8.2  Enhancements  Based  on  Alternative  Architecture  Analysis.  As  mentioned 
in  Section  3.1.1,  previous  research  identified  a  need  to  incorporate  events  ^md  event  process¬ 
ing  within  Architect.  Since  events  are  not  included  in  the  SEI  document,  the  implemen¬ 
tation  considerations  of  events  within  the  OCU  model  should  stay  within  the  spirit  of  the 
OCU  model  (14).  In  other  words,  event  properties  incorporated  in  the  OCU  architecture 
in  Architect  should  not  violate  established  properties  of  the  OCU  model. 

The  incorporation  of  events  led  to  altering  the  Refine  implementation  (within  Archi¬ 
tect)  of  the  OCU  architecture  model  to  include  events  as  part  of  the  architectme.  Adding 
events  required  including  event  processing  and  event  management  within  the  OCU  exe¬ 
cution  model.  The  implementation  details  of  event  processing  amd  event  management  are 
discussed  in  Chapter  VI. 

3.2.3  Event  Processing.  The  initial  step  of  incorporating  events  into  the  OCU 
model  of  Architect  wais  to  identify  the  events  processed  by  a  subsystem.  Since  Architect 
involves  several  research  efforts  (29,  26,  27, 9),  a  consensus  by  research  members  was  needed 
in  the  identification  of  events  and  event  types.  The  consensus  resulted  in  two  different 
classes  of  events  being  identified:  application  events  and  executive  events.  As  the  names 
of  the  events  imply,  the  target  of  each  claiss  of  event  is  either  the  application  subsystem 
being  modeled  or  the  executive  subsystem  of  the  application  executive.  Different  event 
scenarios  highlighted  that  2J1  subsystems  need  to  mauiage  (route)  all  event  types;  however, 
the  actual  processing  of  events  is  left  to  the  appropriate  subsystem.  That  is,  the  executive 
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subsystems  process  executive  events  and  the  application  subsystems  process  application 
events. 

The  goal  of  adding  event  processing  was  to  enhance  Architect’s  OCU  softwEure  zurchi- 
tecture.  This  enhzmcement  included  defining  the  structure  and  information  applicable  to 
the  application  events.  As  a  resialt,  three  application  event  types  were  identified:  Update, 
SetState,  and  NewData.  The  Update  event  is  used  to  tell  a  subsystem  or  primitive  to 
execute.  Likewise,  the  SetState  is  used  to  set  new  attribute  vzdues  within  a  primitive  to 
establish  its  new  state.  Finally,  the  NewData  event  is  passed  to  an  independent  subsystem 
by  the  executive  to  indicate  to  the  subsystem  that  it  has  new  data  in  its  import  area. 

The  next  step  in  incorporating  events  into  Architect  was  to  modify  the  simulation 
capabilities  within  the  present  implementation  of  the  OCU  model  to  handle  events.  As  part 
of  incorporating  event  processing,  we  had  to  preserve  the  sequential  processing  capability 
mentioned  in  Section  3.1.1.  Additionally,  not  only  was  the  passing  of  events  in  the  execution 
of  the  application  important,  but  the  persistence  of  the  events  had  to  be  maintained.  This 
persistence  increases  Architect  potential  for  modelling  truly  concurrent  systems  where 
event  causality  is  important.  The  persistence  requirement  implied  modification  of  the 
subsystems  to  captiore  and  hold  events  being  sent  to  the  subsystem,  as  well  as  capturing 
events  that  the  subsystem  may  have  originated.  Since  Architect  has  a  behavior  simulation 
capability,  the  inclusion  of  events  and  event  processing  imposed  changes  to  the  application 
execution  functions  within  Architect.  The  originzd  execution  programs  only  allowed  for 
sequentizJ  execution  of  an  application  as  derived  by  the  update  algorithm  of  a  subsystem. 
The  new  execution  programs  hzid  to  zdlow  for  the  processing  and  handling  of  events  within 
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the  subsystems.  Further,  the  behavior  simulation  environment  required  the  eiddition  of 
some  new  fimctions  allowing  events  to  be  created  during  the  simulation  of  an  application. 

With  the  inclusion  of  events  and  an  event-driven  simulation  capability  within  Archi¬ 
tect,  the  application  specialist  does  not  input  em  execution  algorithm  as  is  done  with  the 
sequential  mode  of  execution.  This  forced  changes  to  the  semantic  checks  within  Architect. 
The  new  sem2mtic  checks  determined  whether  an  update  algorithm  within  the  controller 
of  a  subsystem  is  legzd  or  not. 

Introducing  events  to  subsystems  is  of  little  use  unless  the  subsystem  knows  what 
to  do  with  the  event.  The  controller  of  a  subsystem  was  enhanced  to  evaluate  events  it 
receives  to  determine  if  it  needs  to  process  the  event  or  route  it  to  another  subordinate 
subsystem.  The  event  implementation  also  reqmred  the  subsystem’s  controller  to  know 
how  to  actuadly  route  the  event  to  any  subordinate  subsystems.  On  the  other  hand,  if 
the  controller  of  a  subsystem  receives  ein  event  that  it  is  to  process,  it  needs  to  interpret 
the  event  and  take  some  action  based  on  the  event  and  event  information  received.  The 
operational  concept  of  event  processing  and  handling  within  a  subsystem  is  provided  in 
section  3.4. 

3.3  Enhancements  As  a  Result  of  Adding  New  Validating  Domains 

Resetirch  involving  comparison  of  the  OCU  software  architectural  model  to  other  soft- 
weire  architectmres  may  not  readily  identify  all  the  potentiEil  shortcomings  within  the  OCU 
model.  While  the  comparisons  with  the  other  architectures  may  identify  a  component  that 
should  be  peat  of  the  OCU  model,  it  may  not  identify  how  to  properly  incorporate  the  this 
component  into  Architect’s  implementation  of  the  OCU  model.  Further,  with  the  limited 
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domain  analysis  of  the  few  problem  spaces  that  sure  now  in  Architect’s  technology  base, 
the  new  component  “may  appear”  to  work.  However,  as  more  domains  are  incorporated 
into  Architect’s  technology  base,  it  may  be  discovered  that  the  initicd  implementation  of 
the  circhitectured  component  was  inadequate.  The  shortcomings  of  any  new  architectural 
component  may  only  be  identified  by  incorporating  new  validating  domains  into  the  OCU 
model. 

To  illustrate  the  above  fact,  the  initial  implementation  of  the  OCU  SetState  oper¬ 
ation  within  Architect  was  inadequate  for  the  event-driven  simulation  capability.  A  new 
SetState  operation  was  needed  to  pass  more  information  than  originally  required  by  the 
sequentieJ  model  of  execution.  Additionally,  einy  use  of  time  delays  required  a  primi¬ 
tive’s  present  state  to  be  persistent  until  a  point  in  time  in  the  future.  By  modifying  the 
functionality  of  the  OCU  SetState  operation,  we  were  able  overcome  simulation  rollback 
problems  regarding  a  primitive’s  state.  This  modification  allowed  a  primitive,  at  a  future 
time  (through  simulating  a  delay),  to  mjike  its  new  state  available. 

One  of  the  other  reseaurch  efforts  at  AFIT  is  to  define  a  domain  model  for  an  ap¬ 
plication  executive  (29).  As  presented  in  Section  3.1.1,  the  validation  of  the  application 
executive  domain  model  will  be  through  the  implementation  of  the  OCU-based  domain 
model  into  Architect.  The  incorporation  of  this  application  executive  domain  model  into 
Architect  forced  additional  refinements  to  the  current  implementation  of  the  OCU  model. 
Mmnly,  the  imports  and  exports  for  subsystems  required  altering.  In  keeping  with  SEI’s 
notion  of  the  imports  and  exports,  as  well  as  copying  an  idea  of  abstraction  from  (3,  20)^, 

'The  consolidation  of  the  imports  and  exports  for  a  subsystem's  subordinate  primitive  at  the  subsystem 
level  with  pointers  back  to  the  owning  primitive 
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Figure  3.1  Two  Independent  Subsystems  within  Architect 


the  imports  and  exports  were  consolidated  into  an  import  area  and  export  area  of  the 
highest  level  (superior)  subsystem  of  an  independent  subsystem.  An  independent  sub¬ 
system  can  be  considered  a  hierarchical  structure  of  subsystems  and  primitives  that  is  a 
self-contained  composition.  Figme  3.1  shows  two  independent  subsystem  with  imports  and 
exports  located  at  the  superior  subsystem. 

The  two  subsystems  in  Figure  3.1  do  not  exhibit  a  parent-child  relationship,  uor  do 
they  share  the  resources  of  their  subordinate  objects.  Independent  subsystems  only  sheire 
information  via  the  import  eind  export  areas;  furthermore,  an  independent  subsystem  is 
unaware  of  the  existence  of  any  other  subsystems.  Finally,  an  independent  subsystem 
exhibits  a  complete  behavior. 

Since  the  inclusion  of  the  application  executive  required  multiply  independent  sub¬ 
systems  to  communicate,  there  needed  to  be  a  central  pleure  to  find  an  independent  sub¬ 
system’s  imports  or  exports.  This  consolidation  of  imports  and  exports  of  an  independent 
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subsystem  had  to  keep  with  the  SEI’s  intention  of  anonymity  of  objects  (subsystems  and 
primitives).  Further,  this  emonymity  had  to  eJlow  for  loose  coupling  between  objects  in  a 
composition  (12). 

3.^^  Operational  Concept  for  Event  Processing 

The  application  composition  process  as  defined  in  (3,  20,  28)  has  not  changed  with 
the  incorporation  of  events;  changes  zure  restricted  to  the  execute  cind  semantic  check 
requirements.  The  highlighted  boxes  in  Figure  3.4  emphasize  the  areas  of  the  overall 
system  design  chcinged  to  zdlow  the  processing  and  management  of  events.  There  are 
additional  changes  required  to  fully  implement  event  processing  in  Architect;  however, 
the  focus  of  this  research  was  with  the  chzmges  required  at  the  subsystem  and  primitive 
level.  The  servicing  of  events  by  the  application  environment,  event  management  for  a 
simulation,  zmd  the  specification  of  the  initial  events  for  an  application  within  Architect  is 
addressed  in  (29). 

With  the  addition  of  an  event-driven  simiilation  mode.  Architect  must  now  query  the 
application  specialist  during  composition  for  the  execution  mode  of  the  application.  This 
information  is  retained  as  paxt  of  the  application’s  definition  and  made  available  to  other 
Architect  components  upon  request.  A  conceptual  model  of  both  the  non-event-driven 
mode  of  execution  and  event-driven  mode  of  execution  within  a  subsystem  can  be  seen  in 
Figures  3.3  and  3.4,  respectively. 

After  the  application  specialist  finishes  composing  a  new  application,  he  is  still  re¬ 
quired  to  rtm  a  semantic  check  against  the  composition.  The  semantic  checks  have  been 
changed  to  check  for  any  Updates  in  the  update  algorithm  of  the  controller  of  em  event 
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Figure  3.2  Requirement  Areas  to  Change  Due  to  Event  Driven  Execution 


Figure  3.3  Conceptual  Model  of  a  Subsystem  in  the  SequentiaJ  Mode 


Figure  3.4  Conceptual  Model  of  a  Subsystem  in  the  Event-Driven  Mode 
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driven  subsystem.  Although  this  is  required  by  the  non-event-driven  mode  of  Architect,  it 
is  illegal  in  the  event-driven  mode. 

Once  the  semantic  checks  are  passed,  the  application  specialist  can  execute  zin  ap¬ 
plication.  The  initial  set  of  events  that  zure  needed  by  Architect  to  stzurt  the  execution  of 
an  application  are  predetermined  by  the  application  specialist.  After  composing  an  appli¬ 
cation,  Architect  prompts  the  application  specialist  for  the  initial  set  of  events  required 
for  the  application  in  order  to  initiate  the  simulation  of  the  application’s  behavior.  The 
prompting  for  initial  events  2md  their  processing  is  addressed  in  (29,  9). 

After  execution  starts,  the  event  manager  of  the  application  executive  selects  an  event 
to  process.  The  event  manager  interprets  the  event  and  determines  the  subsystem  that 
needs  to  process  the  event;  it  then  passes  the  event  to  the  InEvent  area  of  the  appropriate 
independent  subsystem.  Finely,  the  application  executive  passes  the  flow  of  control  to  the 
independent  subsystem  that  received  the  event. 

Upon  receiving  flow  of  control  from  the  executive,  the  subsystem’s  controller  checks 
its  InEvent  area  and  selects  an  event  from  the  InEvent  area. 

The  controller  interrogates  the  event  and  decides  what  needs  to  be  done  next: 

•  If  the  event  is  for  this  particul^u:  subsystem,  the  controller  processes  the  event  and 
invokes  the  appropriate  subordinate  primitive’s  operation,  based  on  the  event  type. 
As  cm  example,  if  the  subsystem  receives  an  Update  event  for  one  of  its  primitives, 
then  the  controller  will  invoke  the  particular  primitive’s  Update  algorithm.  When 
the  primitive  finishes  the  operation,  any  new  events  generated  are  p^lssed  from  the 
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primitive  b^u:k  to  the  superior  subsystem,  which  returns  them  to  the  application 
executive. 

•  If  the  event  is  not  for  this  particular  subsystem  but  for  a  subordinate  subsystem,  the 
subsystem  places  the  event  in  the  subordinate  subsystem’s  InEvent  area  and  passes 
the  flow  of  control  to  the  subordinate  subsystem. 

Subsystems  do  not  do  any  further  processing  on  events  that  are  forwarded  from  subordinate 
objects;  subsystems  only  process  events  that  are  received  from  other  invoking  subsystems. 
After  a  subsystem  has  processed  all  events  in  its  InEvent  area,  it  passes  tdl  newly  generated 
events  in  its  OutEvent  area  back  to  the  caller.  Finally,  before  passing  flow  of  control  back 
to  the  caller,  the  subsystem  clears  both  the  InEvent  and  OutEvent  areas. 

S.5  Summary 

Architect’s  initial  implementation  employed  a  subset  of  the  OCU  model  as  defined 
by  the  SEI.  This  thesis  focuses  primarily  on  defining  a  fraimework  for  comparing  software 
eirchitectures,  ^lnd  determining  the  suitability  of  the  OCU  architecture  model  for  use  in 
application  composition  and  generation  systems. 

This  research  also  includes  expanding  the  OCU  model  within  Architect  to  incorporate 
events  and  event  processing.  This  chapter  discussed  the  changes  to  the  subsystem  and 
primitive  structme  and  the  simulation  capability  as  a  result  of  incorporating  events,  as 
well  as  presented  zin  operational  concept  for  event  processing  within  Architect.  Since  the 
initial  documentation  on  the  OCU  model  does  not  discuss  events,  the  event  types  and 
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structure  of  the  events  held  to  be  identified  in  addition  to  euiy  other  requirements  for  event 
processing  and  management. 

Subsequent  chapters  of  this  thesis  describe  the  framework  for  comparing  software  ar¬ 
chitectures,  the  resiilts  of  comparing  the  alternative  architectures  with  the  OCU  model,  the 
detailed  design  for  events  and  event-driven  simulation  within  Architect,  and  the  validation 
of  event  processing  within  Architect. 
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IV.  Software  Architecture  Comparison  Methodology 


4.1  Introduction 

This  chapter  develops  a  framework  for  comparing  softweure  architectures.  The  frame¬ 
work  includes  a  way  to  compare  software  architectinres  both  syntactically  (structurally) 
emd  semantically  (behaviorally). 

4.2  Framework  for  Comparing  Software  Architectures 

As  mentioned  in  (3:7-5)  and  Section  1.2,  the  OCU  model  needed  to  be  further  eval¬ 
uated  for  its  suitability  as  the  software  architectural  model  for  an  application  composition 
and  generation  system.  In  an  attempt  to  further  evaluate  the  OCU  software  architecture 
model,  I  chose  four  other  software  architectures  to  evaluate  against  it.  These  software 
eurchitectures  axe  MetaH  aa  defined  by  Honeywell  (25),  VHDL  as  defined  by  Lipsett  (15), 
/xRapide  as  defined  by  Luckham  and  Vera  (17),  2ind  hierarchical  softweure  systems  as  defined 
by  Batory  (6,  8).  In  order  to  accurately  compare  the  different  architectures,  a  framework  is 
needed  that  captures  the  salient  points  of  eaich  architecture.  Furthermore,  the  framework 
needed  to  be  capable  of  being  applied  to  all  the  architectures  being  compared. 

The  methodology  for  describing  an  architecture  employed  what  is  commonly  used  to 
describe  einy  object:  a  visual  description  of  the  object  with  some  description  of  its  behav¬ 
ior.  This  perspective  for  evaluating  architectures  closely  correlates  to  Vestal’s  attempt  to 
compare  architectural  description  languages  (24).  He  attempted  to  compcire  the  languages 
syntactically  (structurally)  as  well  as  semantically  (behaviorally). 
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4-2.1  The  Syntax  of  the  Software  Architectures.  A  method  was  needed  to  capture 
the  objects  within  a  software  architecture  and  their  relationships.  For  this  purpose,  Cojui, 
Yourdon,  and  Rumbaugh  recommend  object  diagrams  (7,  22).  The  object  diagrams  for 
each  architecture  are  organized  in  such  a  way  to  show  structural  similarities  between  the 
architectures,  as  well  as  between  the  objects  within  an  architectuire. 

4-2.2  The  Semantics  of  the  Software  Architectures.  Structural  comparison  is  not 
enough  to  substantially  compare  the  architectures.  Just  because  two  objects  are  struc¬ 
turally  the  same  does  not  imply  they  are  the  same  in  other  respects.  For  example,  a  visual 
comparison  of  a  Repeat-  Until  and  a  Do-  While  loop  reveals  that  both  iterate  over  a  set  of 
program  statements  a  number  of  times.  But  closer  inspection  of  the  semantics  of  each  loop 
construct  revejds  the  Repeat-  Until  executes  the  program  statements  at  least  once,  where 
the  Do-  While  may  not  execute  any  of  the  statements.  We  therefore  need  to  examine  the 
behavior  (semantics)  of  the  objects  to  get  a  detailed  understanding  of  what  exactly  the 
object  does.  This  wsdogy  applies  to  software  ju-chitectures  as  well.  Not  only  must  we  com¬ 
pare  the  structures  of  the  architectures,  but  we  must  compare  the  semantics  (behavior)  of 
the  components  of  the  architectures  as  well. 

“Semantics  2u:e  commonly  divided  into  two  classes,  static  semantics  and  dynamic 
semantics”  (13).  Static  semantics  require  that  all  components  exist  and  that  all  components 
and  oper2uids  are  type-compatible.  Dynamic  semantics  specify  what  a  component  does, 
that  is,  what  it  computes.  Axiomatic  definitions  may  be  used  to  model  execution  at  a  more 
abstract  level  than  operational  models  (an  operational  model  explicitly  describes  a  program 
in  terms  of  changes  to  a  defined  state).  Furthermore,  these  definitions  are  based  on  formally 
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specified  relations  or  predicates  that  relate  components.  The  axiomatic  approach  is  good 
for  behavioral  correctness  because  it  avoids  implementation  details  and  concentrates  on 
how  relations  among  variables  are  changed  by  a  “program”  execution  (13).  The  axiomatic 
approach  of  comparing  a  program’s  state  space  is  presented  in  the  next  section,  and  it  is 
used  to  define  the  semantics  of  the  architectural  components  of  the  different  architectures. 

4-2.2. 1  State- Based  Machines.  The  method  chosen  to  compare  the  seman¬ 
tics  of  the  different  architectural  components  is  derived  from  state-based  machines.  The 
choice  of  the  state-based  machine  approach  seems  logical  since  the  objects  contained  in 
object  diagrams  encapsulate  state  information.  By  using  state-based  machines,  the  spe¬ 
cific  engineering  details  of  the  computer  (memory  size,  speed,  etc.)  and  software  (looping 
constructs,  array  implementations,  etc.)  are  “abstracted  out”,  allowing  us  to  concentrate 
on  the  semantics  of  the  architectures  independent  of  any  hardware  or  software  consider¬ 
ations  (4).  By  “abstracting  out”  the  engineering  data,  we  can  more  easily  reason  about 
the  2u:chitectiu:es  as  well  as  the  subsequent  development  of  the  semantics.  Ultimately, 
the  semantics  2u:e  based  on  formal  mathematical  concepts  and  logic,  which  show  program 
correctness.  Before  proceeding  further,  we  provide  a  few  definitions  to  help  explmn  the 
semantics  of  state-based  machines. 

An  abstract  machine  may  be  represented  as  Machine  =  (g,  F)  where: 

•  q  is  the  cmrent  state  of  Machine,  and 

•  F  is  a  set  of  transformations  effecting  state  changes.  If  Q  is  the  state  space  of 
Machine,  then  F  :  Q  — ►  Q. 

•  A  state  q  of  a  Machine  is  given  by  all  the  data  objects  Oj  within  Machine 
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The  abstract  machine  implies  the  underlying  state  space  may  be  defined  by  Q  =  x 
...  X  Q„  where  Qi  is  the  set  of  legitimate  states  of  object  Oi  in  Machine.  Thus,  F  may 
represented  as: 

•  •  •  jQn)  (QitQ2t  •  ■  •  tQn)  where  F  transforms  a  state  of  Q  into  some 

new  state. 

With  the  above  background,  the  semantics  of  an  architectural  component  from  any 
of  the  architectures  can  be  defined  axiomatically.  The  axioms  consist  of  three  elements: 
a  set  of  input  assertions,  a  set  of  output  assertions,  and  a  programming  construct  P. 
The  programming  construct  P  is  used  to  represent  F  in  the  above  transformations.  If 
the  input  assertions  zure  true  prior  to  the  execution  of  the  programming  construct,  and  the 
programming  construct  terminates,  then  the  output  assertions  must  be  true.  The  input  amd 
output  assertions  characterize  the  legitimate  input  and  output  states  for  a  programming 
construct.  The  set  of  input  assertions  are  called  preconditions,  denoted  the  set  of  output 
assertions  ztre  called  postconditions,  denoted  and  the  programming  construct  is  denoted 
P. 

Preconditions  define  constraints  on  the  input  or  data  that  a  program  is  required  to 
handle.  Such  constrmnts  eire  boimds  on  the  size  of  the  program  state  space,  assiunptions 
about  the  input  data,  bounds  on  variables,  and  a  description  of  the  structure  of  the  input 
data.  Postconditions  characterize  exactly  what  the  program  must  achieve.  Postcondi¬ 
tions  eire  usually  the  most  important  part  of  a  program  specification.  They  define  the 
range  of  a  computation.  There  are  three  central  roles  that  postconditions  play  in  program 
development: 
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•  They  provide  a  precise  and  formal  statement  of  what  a  program  or  fimction  should 

accomplish.  Postconditions  describe  what  a  mechemism  does  with  out  regard  to 

“how”  (11:187). 

•  They  can  assist  with  the  constructive  development  of  programs. 

•  They  csm  be  used  in  the  constructive  proof  of  correctness  for  a  program. 

If  a  state  machine  has  a  start  state  ^d  a  set  of  final  states  {^/mai}  (we  will  have 
an  element  of  {q final}  if  the  machine  terminates),  then  the  overall  effect  of  an  abstract 
machine  may  be  defined  as: 

{9o}P{qfinal} 

where  P  is  an  abstract  program  that  transforms  the  the  start  state  qo  to  q final  • 
Using  the  conditions  of  $  and  ^  to  characterize  the  state  space  the  semantics  (or  partial 
correctness)  of  a  program  P  may  be  described  as: 

h  {$}PW+ 

which  is  read  eis:  “If  the  initizd  state  qo  satisfies  condition  $  and  the  program  P  terminates, 
then  the  fined  state  q final  will  satisfy  the  conditions  given  by  ’®'.” 

The  state  space  of  em  abstreict  machine  is  defined  as  a  tuple  of  information.  As  an 
example,  let  Q  =  (Qi  x  Q2  x  Q3)  where  Qi  through  Q3  are  sets  of  Natural  numbers. 
A  program  P  can  be  subdivided  into  program  segments  P  =  Pi,P2,---,Pn-i,Pn-  These 
progreim  segments  axe  used  to  identify  smaller  transformations  of  the  program,  and  specific 
instances  o£  Q  =  Qi  x  ...  x  Qn  can  be  used  as  intermediate  assertions.  Thus,  we  cam 
transform  h  {qo}P{qfinai}  into: 

qo{Pl}qi-,qi{p2}q2;q2{P3}q3-,---;qn{Pn}qfinal  «=►  {9o}P{9/inaj}  ^  {^}P{^}+ 
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where  go  •  •  •  Qfinai  are  specific  instcinces  of  (Ji  x  . . .  x  Q„. 


To  summarize  the  information  above,  the  semantics  of  a  set  of  architectural  compo¬ 
nents  within  a  software  architecture  can  be  seen  as  a  set  of  program  transformations  P 
given  an  initial  state  satisfying  the  precondition  $  resulting  in  a  final  state  satisfying  the 
postconditions  St. 

4-3  Summary 

In  this  chapter,  a  framework  for  comparing  software  architectures  was  presented.  The 
framework  allows  for  compstrison  of  both  the  structiure  of  architectures  and  the  semantics  by 
use  of  preconditions  and  postconditions.  The  next  chapter  presents  the  ^u;tual  comparisons 
of  the  five  software  architectures. 
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V.  Comparison  and  Analysis  of  Five  Software  Architectures 
5. 1  Introduction 

This  chapter  presents  the  results  of  creating  2ui  object  diagram  for  each  software 
architectxure  as  well  as  defining  the  preconditions  and  postconditions  for  each  sirchitectmral 
entity  of  interest.  The  order  of  presentation  of  the  architectures  is  the  OCU  model,  MetaH, 
VHDL,  pRapide,  and  the  IBM  DSSA. 

The  purpose  of  defining  a  framework  for  comp2iring  architectmes  is  to  allow  for  the 
reuse  of  design  and  domain  knowledge  via  transformation  techniques.  With  the  similsurities 
identified,  architectural  components  from  one  model  may  be  transformed  into  architectural 
components  of  another  model  in  a  behavior  preserving  way  without  knowledge  loss. 

The  semzintics  of  the  architectural  entities  of  interest  are  presented  using  the  nomen- 
clatiure  presented  in  Chapter  4,  where  $  is  the  precondition,  P  is  am  abstract 

program  and  ^  is  the  postcondition.  The  postcondition  represents  the  logical  variables  that 
may  potentially  chamge  as  a  result  of  the  execution  of  the  abstract  program  P.  Further,  to 
indicate  a  possible  change  in  state  of  a  logical  variable,  a  Z-like  (pronounced  Zed)  notation 
is  used.  The  Z  notation  is  in  the  form  of  a  tick  (’)  or  decoration  after  the  component,  such 
as,  attribute'  (2). 

5.S  OCU 

The  analysis  of  the  OCU  model  is  based  on  the  information  presented  in  (14)  and 
this  research.  This  research  is  included  in  the  aneilysis  since  this  research  subsumes  the 
axldition  of  events  and  event  processing  to  the  OCU  model. 
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Primitive 


Figure  5.1  Object  Model  for  a  Primitive 


5.2.1  OCU  Syntax.  The  OCU  model  consists  of  primitives,  subsystems  and  an 
application  executive.  The  lowest  level  of  abstraction  is  the  primitive.  A  primitive  has 
inputs,  outputs,  operations,  and  attributes.  The  inputs  amd  outputs  allow  information  to 
enter  and  exit  the  primitive.  The  attributes  hold  the  local  state  information  of  a  primitive. 
Finally,  the  execution  of  the  operations  allow  the  primitive  to  change  state.  Figmre  5.1 
shows  an  object  diagram  of  a  primitive. 

The  next  level  of  abstraction  in  the  OCU  model  is  the  subsystem.  A  subsystem  is 
composed  of  imports  amd  exports,  inevents  amd  outevents,  a  controller,  ais  well  as  sub¬ 
ordinate  primitives  amd  subsystems.  The  subsystem  mamages  its  subordinate  objects,  its 
inevent  amd  outevent  aireais,  amd  the  imports  amd  exports  of  its  subordinate  objects.  The 
mamagement  of  subordinate  objects  is  done  via  the  controller,  which  has  either  am  update 
ailgorithm  or  am  event  manager,  both  of  which  update  the  state  of  th“  subsystem  by  up¬ 
dating  the  state  of  a  subsystem’s  subordinate  objects.  The  update  algorithm  contains  a 
sequence  of  object  updates  (ais  weh  as  other  operations)  that  must  be  performed  in  order  for 
the  subsystem  to  achieve  a  new  state.  In  contraist,  the  event  mamager  processes  inbound 


5-2 


Figure  5.2  Object  Model  for  a  Subsystem 


events  and  handles  outbound  events  in  order  to  cichieve  a  new  state  for  the  subsystem. 
Figure  5.2  is  the  object  model  for  a  subsystem. 

Finally,  the  highest  level  of  abstraction  in  the  OCU  model  is  the  application  executive. 
The  application  executive  is  a  collection  of  primitives  and  subsystems  used  to  support 
execution  of  the  behavior  of  a  composed  application.  Figure  5.3  is  a  composite  object  model 
showing  all  the  components  of  the  OCU  curchitecture  together.  There  is  no  significance  to 
the  shaded,  daished  2uid  solid  type  lines,  they  only  serve  to  help  differentiate  the  different 
relationships  in  the  object  diagram. 


5.2.2  OCU  Semantics.  Normally,  we  only  analyze  the  behavior  of  objects  that 
exhibit  noteworthy  actions  (22:112).  Objects  that  exhibit  interesting  behavior  within  the 
OCU  model  axe  the  primitive  emd  subsystem  objects.  These  are  the  aurchitectural  entities 
whose  semantics  aire  amalyzed. 


5.2.2. 1  Primitive.  A  primitive’s  semantics  can  be  seen  in  Figure  5.4.  Note 
that  progr2im  P  is  composed  of  the  Operations  identified  in  the  box.  $  is  represented  eis 
the  following: 
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Figure  5.3  Complete  OCU  Object  Model 


Attributei  ...Attributej, 

=>■  (OutEventi  ...OutEventy) 

Coefficienti...Coefficientm 
Constanti  ...Constantx 

(Inputi... Input j)  {Outputi—Outputi) 

Operati<m\...OpeTcttionp 

Figrire  5.4  Diagram  of  an  OCU  Primitive  Behavior 
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{Validlnpui{lnputi)  A  ...  A  Validlnput{lnputj))  A  {{Attributei, ,  AttributCn), 

(Coefficienti,. . .  ,Co€fficientm),  (Constanti,. . .  ^Constant^)}  6  V alidState Space 

“Veilidinput”  is  a  predicate  that  evaluates  an  Input  eind  ensures  that  the  input  value 
being  peissed  to  the  Primitive  is  of  a  type  the  primitive  can  input  emd  within  bovmds. 
Additionsilly,  “ValidStateSpace”  is  the  cross  product  of  all  the  legitimate  state  spaces  that 
a  primitive  can  occupy  based  on  its  Attribute,  Coefficient,  and  Constant  values.  The 
precondition  above  requires  that  the  Input  values  are  of  the  correct  type  and  range,  and 
the  values  of  the  Attributes,  Coefficients  and  Const2uits  together  form  a  vEilid  state  space 
for  the  primitive. 

Two  different  postconditions  are  presented  for  the  transformation  process  P  on  a 
primitive.  The  first  for  a  primitive  represents  the  the  transformation  as  a  result  of 
applying  the  SetState  and  Update  for  the  general  OCU  model. 


1.  If  P  represents  a  SetState  operation  then 

{Attribute'^  =  P{Attributei))  V  {Coefficient\  =  P{Coefficienti)) 

2.  If  P  represents  an  Update  operation  then 

{Attribute'^, . . . ,  Attribute'^  =  P{{AUribut€i, . . . ,  Attribute„),  {Inputi, . . . ,  Input j), 
{Coefficienti, ...,  Coe  ffidentm),  {Constanti ,...,  Constantx))  A 

{Input'i ,...,  Inputj)  =  P  {{Attributei, ...,  Attributen),  {Inputi, ...,  Inputf), 

{Coef  ficienti, . . . ,  Coef  ficientm),  {Constanti ,. ..,  Constantx))  A 

{Output'i, ...,  Output'i)  =  P  {{Attributei, ...,  Attribute„),  {Inputi,  •  •  •  >  Input  j), 
{Coefficienti, ...,  Coefficientm),  {Constanti ,...,  Constantx)) 

The  i  subscript  in  a  postcondition  uniquely  identifies  an  Attribute  or  Coefficient  that 
is  to  change.  The  postcondition  of  a  non-event-driven  execution  implies  that  as  a  result 
of  the  transformation  process  of  P  (P  representing  a  SetState  operation),  an  Attribute 
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or  a  Coefficient  value  hcis  changed.  Likewise,  the  postcondition  (where  P  is  an  Update 
operation)  indicates  that  the  Attribute,  Input,  and  Output  values  have  chemged. 

The  second  represents  the  transformation  of  a  primitive  based  on  our  implementa¬ 
tion  of  the  OCU  model  in  Architect.  Due  to  event-driven  simulation,  this  transformation 
differs  from  the  one  above. 


1.  If  P  represents  a  SetState  operation  then 

{Attribute'^, . . . ,  Attribute'^)  =  P{{Attributei, . . . ,  AttributCn),  {Inputi, . . . ,  Input j), 
{Coefficiently . . .  yCoefficientm),  {Constantly. . .  yConstantx))  A 

{OutEvent'iy , . .  yOutEvent'y)  =  P{{Attributei, . . . ,  {Inputiy . . .  y Input j)y 

{Coefficiently . . . ,  Coef  ficientm)y  {Constanti , . . . ,  Constantx))  A 

{Input'iy. . .  y  Input'j)  —  P{{Attributeiy . . . ,  Attributen)y  {Inputiy . . . ,  Input j)y 
{Coe fficienti , . . . ,  Coef  fidentm),  {Constanti , . . . ,  Constantx))  A 

{Output'iy . . . ,  Output'^  =  P{{Attributeiy . . . ,  Attributen)y  {Inputiy . . . ,  Inputj)y 
{Coef  ficientiy . . .  yCoefficientm),  {Constantly. . .  yConstantx)) 

2.  If  P  represents  am  Update  operation  then 

{OutEvent'iy . . . ,  OutEvent'y)  =  P{{Attributeiy . . .  y  AttributCn) y  {Inputiy . . . ,  Input j)y 
{Coef  ficientiy . . . ,  Coef  ficientm)y  {Constantly . . .  yConstantx)) 

The  postcondition  implies  that  as  a  result  of  the  transformation  process  of  P  (P 
representing  a  SetState  operation),  the  Input,  Attribute,  OutEvent  and  Output  values 
change.  Similcirly,  the  postcondition  of  the  transformation  process  (where  P  represents 
am  Update  operation)  is  the  generation  of  some  OutEvents.  Changing  any  of  these  values 
dictates  that  a  primitive  has  changed  state. 


5. 2. 2. 2  Subsystem.  The  subsystem’s  semamtics  cam  be  seen  in 

Figmre  5.5.  The  state  of  am  OCU  Subsystem  is  a  composition  of  all  the  state  information 
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U  pdateAlgorithm 

(InEvent\  . . .  InEventi, )  =>  ^  (OutEventi  .  ■ .  OutEventy ) 

Primitivei . . .  Primitive^ 

(Injmti  . . .  Input j )  =>  =>  (Outputi  . . .  Output, ) 

Subsystemi . . .  Suhayitemf 

Figiire  5.5  Behavioral  Model  for  an  OCU  Subsystem  With  Subsystems  and  Primitives 

of  its  subordinates.  As  such,  when  a  subordinate  object  to  a  subsystem  changes  state,  the 
subsystem  itself  has  changed  state.  Note  that  program  P  represents  either  the  sequential 
execution  of  the  UpdateAlgorithm  or  the  execution  of  some  operation  of  a  subordinate 
object  based  on  an  event  received.  $  can  be  represented  as  the  following: 

(V alidlnput{lnputi)  A  ...  A  Validlnput{lnputj))  A 

(yaHdEvent(InEventi)  A  ...  A  ValidEvent^InEventk))  A 

{(Primitivei , . . . ,  Primitive^),  (Subsystemi , . . . ,  Subsystemp)}  €  V alidStateSpace 

“ValidEvent”  is  a  predicate  that  evaluates  an  InEvent  to  ensure  the  target  ''  the 
inbound  event  is  this  subsystem.  Also,  “ValidStateSpace”  represents  the  cross  product  of 
all  the  legitimate  state  spzw:es  that  a  subsystem  can  occupy  based  on  the  state  space  of  its 
subordinate  Primitives  and  Subsystems.  The  precondition  above  requires  that  the  Input 
values  are  of  the  correct  type  and  within  boimds,  the  InEvents  are  for  this  subsystem,  and 
the  state  space  of  the  subordinate  Primitives  and  Subsystems  together  form  a  valid  state 
space  for  the  subsystem. 

In  the  non-event-driven  transformation  process  for  the  general  OCU  model,  P  rep¬ 
resents  the  sequential  execution  of  the  operations  in  the  UpdateAlgorithm.  "if  is: 

(Primitive'i, . . . ,  Primitive!^)  =  P  ((Primitivei, . . . ,  Primitive,,),  (Inputi, . . .,  Input  j), 
(Subsystemi , . . . ,  Subsystemp))  A 

(Subsystem'i, . . . , Subsystem^)  =  P ((Primitivei, . . . , Primitive^),  (Inputi,. . . , Inputj), 
(Subsystemi Subsystemp))  A 
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{Input[, Input'j)  =  P{{Primitivei , . . . ,  Primitive^),  {Inputi, Input  j), 
{Subsystemi Subsystenip))  A 

{Output^,. . . ,  Output'^)  =  P  {{Primitively .  •  • » Primitively)  y  {Inputiy ,  Inputj), 
{Subsystemi , . . . ,  Subsystemp)) 

The  postcondition  of  a  subsystem  for  a  non-event-driven  execution  implies  that  the 
subsystem  as  a  whole  has  changed  state,  including  subordinate  Primitives  and  Subsystems. 
The  Input  and  Output  values  of  the  subsystem  have  also  changed.  The  reeison  the  Input 
A^ues  can  ch^lnge  eis  a  result  of  the  transformation  process  is  due  to  the  possibility  of 
feedback. 


With  the  introduction  of  events  to  the  OCU  model  of  Architect,  a  subsystem  exhibits 
a  different  behavior.  After  an  event-driven  transformation  process  of  P,  is: 

1.  If  F  represents  a  SetState  event  for  a  subordinate  object  then 

{{Primitive'i  =  P{Primitivei))  V  {Subsystem'^  —  P {Subsystemi)))  A 

{{OutEvent'iy . . . ,  OutEvent'y)  =  P{Primitivei)  V  P{Subsystemi))  A 
{{Input'iy . ..,  Input'j)  =  P{Primitivei)  V  P {Subsystemi))  A 

{{Output'iy ... ,  Output'^  =  P{Primitivei)  V  P  {Subsystemi)) 

2.  If  P  represents  ^m  Update  event  for  a  subordinate  object  then 
{OutEvent'i, . . .  yOutEvent'y)  =  P{Primitivei)  V  P{Subsystemi) 

The  i  subscript  in  the  postcondition  uniquely  identifies  a  particular  Primitive  or 
Subsystem  that  is  the  target  of  the  event.  The  postcondition  for  the  transformation  process 
(where  P  is  a  SetState  event)  dictates  that  the  imiquely  identified  subordinate  Subsystem 
or  Primitive  changes  state,  as  well  as  some  OutEvent,  Output,  and  Input  values.  The 
postcondition  of  the  transformation  process  P  for  an  Update  event  indicates  that  only  the 
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OutEvents  of  a  subsystem  change  as  a  result  of  the  event  being  processed  by  some  uniquely 
identified  subordinate  Subsystem  or  Primitive. 

5.3  MetaH 

5.3.1  MetaH  Syntax.  A  MetaH  architecture  is  specified  using  eight  diflPerent 
objects.  The  most  primitive  of  these  entities  is  a  subgroup  called  source  entities;  they 
are  port  types,  subprograms,  packages,  and  monitors.  Source  entities  have  hnks  to  soft¬ 
ware  source  modules.  The  next  higher-level  abstraction  is  a  process;  a  process  entity  is 
a  grouping  of  source  entities.  As  processes  are  groupings  of  source  entities,  macros  and 
modes  are  higher-level  groupings  of  processes.  Likewise,  processes,  macros  and  modes  can 
be  grouped  to  form  a  higher-level  mode  or  macro  abstraction.  Finally,  the  highest-level 
abstraction  is  an  application.  The  application  contains  all  the  information  needed  to  an¬ 
alyze  a  design  against  real-time  constraints,  as  well  as  actually  generate  code  for  a  target 
system.  An  application  even  contains  a  heirdware  description  file  for  the  target  system, 
which  is  used  during  actual  code  generation.  In  order  to  specialize  somrce  modules,  MetaH 
entities  contain  local  attributes.  Figures  5.6,  5.7,  and  5.8  are  object  models  for  MetaH 
source  entities,  MetaH  higher-level  objects  and  a  composite  MetaH  model,  respectively. 
The  shaded,  dzished  and  solid  type  lines  signify  the  different  relationships  in  the  object 
model. 

5.3.2  MetaH  Semantics.  Objects  that  exhibit  interesting  behavior  within  MetaH 
are  the  source  entity,  process,  macro,  and  mode  objects.  These  are  the  architectural  entities 
whose  semantics  are  analyzed. 
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Source  Entity 


Attribute 


MetaH  Source  Entity  Object  Model 


0 


Figure  5.7  MetaH  Higher-Level  Abstractions  Object  Model 


Figure  5.8  MetaH  Complete  Object  Model 


AttTihute\  . . .  AttrifrufCn 

(/nputi  . . .  Input j )  =>  _  =>•  (OutEventi  . . .  OutEvent^ ) 

=>  {Outputi  . . .  Outputi) 

SourceModttlei  . . .  SourceModulcm 


Figure  5.9  Behavior  of  a  MetaH  Source  Entity 
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{InEventi  . . .  InEventi, )  ^ 


(/npttti  . . .  Input] )  => 


Attriiittei  . . .  Attribute. 

Pathi . . .  Path, 

SourceEntitpi  . . .  SourceEntitym 


=>  (Out£venti  . . .  OutEvent^ ) 


=>  (Outputi  . . .  Output, ) 


Figure  5.10  Behavior  for  a  MetaH  Process 

5. 3. 2. 1  Source  Entity.  A  source  entity’s  semantics  can  be  seen  in  Figvire  5.9. 
Note  that  program  P  represents  any  subset  of  SourceModules  identified  in  the  box.  $  can 
be  represented  as  the  following: 

{Validlnput{lnputi)  A  ...  A  V  alidlnput{lnputj))  A  {{Attributci, Attributen)} 

€  V alidStateSpace 


“Validinput”  for  the  MetaH  model  represents  a  predicate  that  evaluates  an  Input 
and  ensures  that  the  input  value  being  passed  to  the  source  entity  is  of  a  type  the  source 
entity  can  input  and  within  boimds.  Also,  “ValidStateSpace”  represents  the  cross  product 
of  all  the  legitimate  state  spaces  that  a  source  entity  cw  occupy  based  on  its  Attribute 
values.  The  precondition  above  requires  that  the  Input  values  are  of  the  correct  type  and 
range,  and  the  values  of  the  Attributes  form  a  valid  state  space  for  the  soiurce  entity. 

As  a  result  of  the  trmsformation  process  of  P,  ^  will  be  the  following: 

{Input'i, . . . ,  Input'j)  =  P{{Attributei,. . . ,  AttributCn),  {Inputi, . . . ,  Input,))  A 
{Output',, . . . ,  Output'^  =  P{{Attribut€i, . . . ,  Attribute„),  {Input,, . ..,  Inputj))  A 
{OutEvent',, . . .  ,OutEvent'y)  =  P{{Attributei, . .  .,Attributen),  {Inputi, . . ., Inputj)) 

The  postcondition  indicates  that  as  a  result  of  the  transformation  process  of  P,  the 
Input,  Attribute,  OutEvent  and  v>utput  values  change  for  a  source  entity.  The  changing 
of  the  Input  values  are  due  to  the  possibility  of  feedback. 
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5. 3. 2.2  Process.  Process  semantics  C2in  be  seen  in  Figure  5.10.  The  state 
of  a  MetaH  process  is  a  composite  of  its  Attribute  values  and  the  state  information  of  its 
subordinate  source  entities.  Note  that  program  P  represents  the  execution  of  some  Path. 
$  for  a  process  can  be  represented  as  the  following: 

{Validlnput{lnputi)  A  ...  A  Validlnput{lnputj))  A 

{ValidEvent{InEventi)  A. .  .AValidEvent{InEventtc))A{{Attributei, . . . ,  AtiributCn) , 
{SourceEntityi, . . . ,  SourceEntitym)^  {Pathi, . . . ,  Pathf)}  6  V alidStateSpace 

The“ValidEvent”  is  a  predicate  that  evaluates  an  InEvent  to  ensure  the  target  of  the 
inbound  event  is  this  Process.  “ValidStateSpace”  represents  the  cross  product  of  2J1  the 
legitimate  state  spaces  that  a  process  can  occupy  based  on  its  Attribute  values,  subordinate 
SolurceEntities,  zmd  Paths  of  execution.  The  precondition  above  requires  that  the  Input 
values  are  of  the  correct  type  and  within  bounds,  the  InEvents  are  for  the  Process,  and 
the  values  of  the  Attributes  along  with  the  state  space  of  its  SourceEntities  as  constrained 
by  Paths  define  a  valid  state  space  for  a  process. 

As  a  result  of  the  transformation  process  of  P,  will  be  the  following: 

{SourceEntity[, . . . ,  SourceEntity'^)  =  P{{Attributei, . . . ,  AttTibute„), 

{Inputi, . . . ,  Input j) ,  {InEventi^ . . .  ,InEv€ntk), 

(SourceEntityi ,...,  Source  Entitym))  A 

(Attribute'i, ...,  Attribute'^)  =  P({Attributei, . . . ,  Attributen),  (Inputi,  Input  j), 

(InEventi ,...,  InEventk),  (SourceEntityi ,...,  SourceEntityi))  A 

(Input'i, . . .  ,Input'j)  =  P((Attributei, ...,  Attributen) ,  (Inputi,  •  • .,  Input  j), 

(InEventi, . . . ,  InEventk),  (SourceEntityi, . . . ,  Source  Entitym))  A 

(InEvent'i ,. ..,  InEvent'k)  =  P((Attributei, ...,  Attribute„),  (Inputi,  ■  •  ■ ,  Input  j), 
(InEventi,.  •  ■  j  InEventk),  (SourceEntityi, . . . ,  SourceEntitym))  A 

(Output'i, ...,  Output'^  =  P((Attributei, ...,  Attributen),  (Inputi, ...,  Input  j), 

(InEventi  ,  InEventk),  (SourceEntityi ,...,  SourceEntitym))  A 

(OutEvent'i ,... ,  OutEvent'y)  =  P((Attributei, ...,  Attributen),  (Inputi, ... ,  Input  j), 
(InEventi ,...,  InEventk),  (SourceEntityi ,...,  SourceEntitym)) 
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(InEventi  . . . InEventt)  => 
(Inputi  . . .  Input j )  =» 


=>  {OutEventi  . . .  OutEventy ) 
{Ouiputi  . . .  Outputi ) 


Aitributei  . 

.  Attributen 

Pathi  • 

.  Path, 

Macroi  . 

.  Macro, 

Processi  ■ 

.  Process^ 

Figure  5.11  Behavior  for  a  MetaH  Macro 

The  postcondition  states  that  as  a  result  of  the  transformation  process  of  P,  the 
Input,  InEvent,  Attribute,  OutEvent  and  Output  values  have  changed.  Also  the  state  of 
the  process’  subordinate  SourceEntities  have  changed  state.  Changing  in  the  Input  values 
and  InEvents  2o:e  due  to  feedback. 

5.S.2.3  Macro.  The  macro’s  semantics  can  be  seen  in  Figure  5.11.  As 
with  a  process,  a  macro’s  state  is  a  composite  of  its  Attribute  values  and  the  state  space 
of  its  subordinate  objects.  Program  P  represents  the  execution  of  some  Path.  $  can  be 
represented  as  the  following: 

{Validlnput{lnputi)  A  ...  A  Validlnput{lnputj))  A 

{ValidEvent{InEventi)A. .  .AValidEvent{InEventk))A{{Attributei, . . . ,  Attribute„), 
(Processi , . . . ,  Processm )  >  {Macro^ , . . . ,  Macro^ ) , 

{Pathi . . .  Pathx)}  €  ValidStateSpace 

“ValidStateSpace”  for  a  m^lcro  is  the  cross  product  of  all  the  legitimate  state  spaces 
that  a  macro  cein  occupy  based  on  the  veilues  of  its  Attributes,  the  state  space  of  its  subor¬ 
dinate  Macros  and  Processes,  as  restricted  by  the  execution  Paths.  The  above  precondition 
dictates  that  the  InEvents  received  are  for  the  macro,  the  Inputs  eire  of  the  correct  type 
eind  range,  and  the  state  sp2w:e  for  a  macro  is  defined  by  its  Attribute  vfJues,  Macros, 
Processes,  eind  execution  Paths. 

After  the  trauisformation  process  of  P,  ^  will  be: 
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(InEventi  . . .  InEvent/, )  => 
(Inputi  . . .  Input j)  ^ 


Attributei  . 

■  Attribute,, 

Pathi  . 

.  Path, 

Mode,  . 

.  Modcv, 

Macroi  . 

.  Macro, 

Processi  ■ 

.  Process,„ 

=>  (OutEventi  . .  .OutEvent^) 
=>  (Outputi  . . .  Output, ) 


Figure  5.12  Behavior  for  a  MetaH  Mode 


{Process'^,. . . ,  Process'^)  =  P{{Attributeiy Aitribut€„} ,  (Inputi,  ■  •  • » Inputj), 

(InEventi,. . .  ,InEventk),  (Processi,.. .  ,ProcesSm),  (Macroi, . . . , Macro,,))  A 

(Macro'i, . . . ,  Macro'^)  —  P((Attributei, . . .  ,Attributen),  (Inputi,  •  •  •  ^  Inputj), 

(InEventi,. . .  ,InEventk),  (Proceasi,. . .  ,Proce8Sm),  (Macroi,. . .,  Macro,))  A 

(Attribute'i, . . . ,  Attribute',,)  =  P((Attributei, . . . ,  AttributCn),  (Inputi,.  •  •  >  Inputj), 
(InEventi,. . . ,  InEventk),  (Processi,. . . ,  ProcesSm),  (Macroi, ...,  Macro,))  A 

(Input'i, . . .,  Input' j)  =  P((Attributei, . . .  ,Attributen),  (Inputi,.  •  • ,  Inputj), 

(InEventi,. . . ,  InEventk),  (Processi,. . .  ,Proce8Sm),  (Macroi, ...,  Macro,))  A 

(InEvent'i, . . . ,  InEvent'k)  =  P((Attributei, ...,  Attribute,,),  (Inputi, . . . ,  Inputj), 

(InEventi,. . .,  InEventk),  (Processi,. . .  ,ProcesSm),  (Macroi,. . .,  Macro,))  A 

(Output'i, ...,  Output'j)  =  P((Attributei, ...,  AttributCn),  (Inputi, ...,  Inputj), 

(InEventi, . . . ,  InEventk), (Processi, . . . ,  Proceasm),  (Macroi, ...,  Macro,))  A 

(OutEvent'i, . . . ,  OutEvent'y)  =  P((Attributei, ...,  Attribute^),  (Inputi, ... ,  Inputj), 
(InEventi,. . . ,  InEventk),  (Proceaai,. . .  ,Proceaam),  (Macroi,.. . ,  Macro,)) 


The  postcondition  of  a  mzwro  implies  that  the  macro  as  a  whole  has  changed  state, 
including  its  subordinate  Processes  and  Macros.  Also  changed  as  a  resxilt  of  the  trans¬ 
formation  process  P  eire  the  Attribute,  Input  and  Output  values,  and  the  InEvents  and 
OutEvents  of  the  macro.  Feedback  is  the  cause  for  the  InEvents  and  Input  values  changing 
Jis  a  result  of  the  tr8msformation  process. 


5. 3.2.4  Mode.  The  mode’s  semantics  can  be  seen  in  Figure  5.12.  As  with 
a  macro,  a  mode’s  state  is  a  composite  of  its  Attribute  vedues  and  the  state  space  of  its 
subordinate  objects.  Note  that  program  P  in  mode  must  represent  the  execution  of  some 
Path  from  the  figure.  $  cein  be  represented  as  the  following  list: 
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{y alidlnput{lnputi)  A  ...  A  V alidlnput{lnputj))  A 

{y c.lidEvent{InEventi)A. .  .AValidEvent(InEventi,))A{{Attributei, . . . ,  AttributCn) , 
(Processi, . . . ,  Process^),  {Macroi,. . .  ^MacrOx),  {Modci, . . .  ,Mode^), 

{Pathi, . . . ,  Pathx)}  G  V alidStateSpace 

“ValidStateSpace”  for  a  mode  is  the  cross  product  of  all  the  legitimate  state  spaces 
that  a  mode  can  occupy  based  on  the  values  of  its  Attributes,  the  state  space  of  its  subor¬ 
dinate  objects,  as  restricted  by  the  execution  Paths.  The  above  precondition  requires  that 
the  InEvents  received  are  for  the  mode,  the  Inputs  are  of  the  correct  type  ^md  r^lnge,  cind 
the  state  space  for  a  mode  is  defined  by  its  Attribute  values.  Modes,  Macros,  Processes, 
and  Paths. 

After  the  transformation  process  of  P,  will  be: 

(Process^ Process'^)  —  P((AUribuiei, . . . ,  Attributen),  {Inputi, ...,  Input  j), 
{InEventi, ...,  InEventk),  {Processi,. . . ,  Processm),  {Macroi, ...,  Macrox), 
{Model,...,  Mode^u))  A 

{Macro[,. . . ,  Macro'x)  =  P{{Attributei, ...,  Attributen),  [Inputi,. . . ,  Input  j), 
{InEventi,. . . , InEventk),  {Processi,. . .  ,ProcesSm),  {Macroi, . .  .,Macrox), 

{Model ,...,  Mode,o ) )  A 

{Mode[, ... ,  Macro',^)  =  P{{Attributei, . . .,  Attributen),  {Inputi,. . ., Input  j), 

{InEventi, . . . , InEventk),  {Processi,. . .  ,Processm),  {Macroi, . .  .,MacrOx), 
{Model, ...  ,Mode,u))  A 

{Attribute^, . . . ,  Attribute',^)  =  P{{Attributei, ...,  Attributen),  {Inputi,  ■■■,  Input,), 
{InEventi,.  •  • ,  InEventk),  {Processi,. . . ,  ProcesSm),  {Macroi, . . .  ,MacTOx), 

{M odci, . . . ,  M ode^,))  A 

{Input',, . ..,  Input'j)  =  P{{Attributei, . . .,  Attributen),  {Inputi,  •  •  •  >  Inputj), 

{InEventi,. . . ,  InEventk),  {Processi,. . . ,  Process^),  {Macroi, ...,  MacrOx), 
{Model,. ..  ,Modew))  A 

{InEvent', ,...,  InEvent'^)  =  P{{Attributei, ...,  Attributen),  {Inputi,  •  •  • ,  Inputj), 
{InEventi, ...,  InEventk),  {Processi,. . . ,  Process^),  {Macroi, ...,  MacrOx), 
{Model,. ..  ,ModeJ))  A 

{Output',, ...,  Output'^)  =  P{{Attributei, ...,  Attributen),  {Inputi,  •  •  • ,  Input,), 
{InEventi,. . . ,  InEventk),  {Processi,. . . ,  Process„i),  {Macro,, ...,  MacrOx), 
{Mode,,. . .  ,ModeJ))  A 
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{OutEvent[, . . . ,  OutEventy)  =  P{{Attribut€i, . ,  Attribute„),  {Inputi, . . . ,  Input  j), 
{InEventi,. . .  ,InEventk),  {Processi,. . . ,  Process,n),  {Macroi, ,  Macros), 
{Model,. . . ,  Mode,,,)) 

The  postcondition  of  a  mode  indicates  that  the  mode  as  a  whole  ha*  changed  state, 
including  its  subordinate  Processes,  Macros  and  Modes.  Also  chcmged  as  a  result  of  the 
transformation  process  P  are  the  Attribute,  Input  and  Output  values,  and  the  InEvents  and 
OutEvents  of  the  mode.  Input  values  emd  InEvents  change  as  a  result  of  the  transformation 
process  due  to  the  possibility  of  feedback. 

5.4  VHDL 

5.4-1  VHDL  Syntax.  The  object  diagram  for  VHDL  is  shown  in  Figure  5.13. 
Since  the  object  model  for  VHDL  is  relatively  simple,  we  chose  not  to  present  portions  of 
it  at  a  time  but  in  its  entirety. 

All  items  to  be  modelled  in  VHDL  eire  classified  as  processes.  A  process  can  be 
further  divided  into  entities  or  components.  An  entity  is  a  stand-alone  executable  process 
within  the  VHDL  environment.  An  entity  is  a  complete  application  whose  behavior  can 
be  modelled;  it  is  not  an  architectural  fragment  of  some  larger  construct.  On  the  other 
hand,  components  can  not  stand  alone  or  be  executed  by  themselves;  components  axe 
architectural  fragments  that  are  used  in  the  development  of  larger  constructs.  We  present 
some  examples  to  emphasize  the  difference  between  VHDL  entities  and  components: 

•  An  and  gate  can  be  a  entity  where  its  behavior  is  simulated  and  modelled. 

•  A  J-K  flipflop  can  be  an  entity. 
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Figure  5.13  VHDL  Object  Model 
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(/nSi^naii  .  .  .  /nSiynaf^)  ^ 


Aitrtftttici  ■ .  .  AtlrtbuiCn 


Operation 


=»  (OufSignaii  ■  ■  .  Ottt5t9na/|,) 


Figure  5.14  Behavior  of  a  VHDL  Component 


•  Nand  and  nor  gates  are  considered  components  when  composed  together  in  the  design 
of  a  J-K  flipflop.  The  overall  J-K  flipflop  circuit  would  still  be  considered  an  entity. 

•  If  the  J-K  flipflop  above  is  used  in  the  development  of  an  even  larger  application, 
it  would  then  be  a  considered  a  component,  and  the  larger  application  would  be 
considered  an  entity. 


The  important  difference  between  an  entity  and  a  component  is  level  of  abstraction.  An 
entity  is  an  application,  while  its  identifiable  subparts  are  components. 

Information  enters  and  exits  a  process  via  ports  in  VHDL.  A  port  can  have  one  of 
four  modes:  in,  out,  inout,  and  buffer.  Processes  share  information  by  sending  signals 
between  processes.  Signals  are  used  to  coordinate  communication  among  all  processes. 
Port  connections  eire  directional;  that  is,  the  information  flows  from  one  port  to  another 
in  the  direction  specified  by  the  port’s  mode  (in,  out,  inout).  Buffer,  however  is  a  special 
case  of  inout. 


5.4-2  VHDL  Semantics.  Objects  that  exhibit  interesting  behavior  within  VHDL 
aire  the  entity  and  component  objects.  These  are  the  architectural  entities  whose  semantics 
are  analyzed. 

5. 4-2.1  Component.  A  component’s  semantics  can  be  seen  in  Figme  5.14. 
Program  P  is  the  Operation  identified  in  the  box.  $  can  be  represented  ais  the  following: 
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(/nSifnafi  . .  .  /nSiyna/^)  ^ 


.  ■  .  v4<«ri&«<c  n 

Componcnti  . . .  Componcnim 
Operation 


^  (Ouf5t9n«/l  .  .  .  0«<5i9f>a/y ) 


Figtire  5.15  Behavior  of  a  VHDL  Entity 


{V alidInput{InSignal\)  A  ...  A  V alidlnjmt^InSignalk))  A 
{Attributei, . . . ,  AttributCn}  6  ValidStateSpace 

“Validinput”  for  a  VHDL  component  is  a  predicate  that  evaluates  an  InSignal  to 
ensure  that  tli  >1  InSignal  is  for  this  component  to  process.  Also,  “ValidStateSpace”  is  the 
cross  product  of  all  the  legitimate  state  spaces  that  a  component  cam  occupy  based  on  its 
Attributes.  The  precondition  dictates  that  the  InSignals  are  for  this  component  and  the 
values  of  its  Attributes  form  a  valid  state  space  for  the  component. 


As  a  result  of  the  transformation  process  of  P,  ’J'  is  the  following: 

{Attribute'^, . . . ,  Attribute'^)  =  P{{Attributeif . . . ,  Attribute„), 
{InSignali nSignalk) )  A 

{InSignal'i, ...,  InSignal'^)  =  P{{Attributei, . . . ,  Attribute„), 
(InSignali, . .. ,  InSignal^))  A 

(OutSignal'i, . . .  ,OutSignal'^)  =  P{{Attributei, . . .  ,Attribute„), 
(InSignali, . . . ,  InSignalk)) 


The  postconditions  imply  that  as  a  result  of  performing  a  transformation,  the  At¬ 
tribute  values,  InSignals,  and  the  OutSignals  of  a  component  have  changed.  Changes  in 
the  InSignals  dmring  this  transformation  axe  caused  by  the  possibility  of  feedback. 


5. 4-2. 2  Entity.  The  entity’s  semaintics  can  be  seen  in  Figure  5.15.  Note  that 
program  P  represents  a  distinct  Operation  (if  the  entity  is  not  composed  of  subordinate 
Components)  or  the  tremsformation  of  any  of  the  entity’s  subordinate  Components.  $  can 
be  represented  as  the  following: 
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{ValidInput{InSignali)  A  ...  A  ValidInput{InSignalk))  A 

{{Attributei,. . . ,  Attributen),{Componenti, . . .  ,Comp(mentm)}  G  V alidStateSpace 

The  “VzdidStateSpace”  represents  the  cross  product  of  all  the  legitimate  state  spaces 
that  an  entity  can  occupy  based  on  its  Attribute  values  and  the  state  space  of  subordinate 
Components.  The  precondition  above  dictates  that  the  InSignads  are  for  this  entity,  amd 
the  state  spaice  defined  by  the  Attributes  amd  Components  forms  a  vadid  state  space  for 
the  entity. 


After  the  transformation  process  of  P,  is: 

(Attribute'i, . . . ,  Attribute'^)  =  P{{Attributei, Attributen), 

{InSignali, . . .  ,InSignalk),{Componenti,. . .  ,Componentm))  A 

(Component[, . . ,  ,Component'^)  =  P{{Attributei,...,Attributen), 
{InSignali, . . . ,  InSignalk),  (Componenti, . . . ,  Component^))  A 

{InSignal'i, . . . ,  InSignal'k)  =  P{{Attributei,...,Attributen), 

(InSignali, ...,  InSignalk),  (Componenti,. . . ,  Componentm})  A 

(OutSignal'i, . . . ,  OutSignaly)  =  P((Atlributei, ...,  Attributen)i 
(InSignali, . . . ,  InSignalk),  (Componenti,. . . ,  Component,,,)) 


The  postconditions  imply  that  as  a  result  of  performing  a  transformation  P,  the 
Attribute  Aradues,  subordinate  Components,  InSignads,  and  the  OutSignals  of  an  Entity 
have  changed.  The  chainging  of  the  InSignals  results  from  feedback. 


5,5  fiRapide 

5.5.1  fiRapide  Syntax.  There  au:e  four  main  featiures  in  ^Rapide:  event  patterns, 
components  (amd  their  corresponding  interfaice),  architectures,  and  mappings.  Event  pat¬ 
terns  are  used  by  other  constructs  to  allow  access  to  behavior,  constradnts,  and  mappings. 
An  interfaice  to  a  component  defines  how  objects  react  to  events,  how  objects  change  state, 
and  how  objects  generate  new  events.  Components  can  model  a  small  object  like  a  circuit 
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gate  or  a  large  object  like  an  airplane.  Architectures  on  the  other  hand  define  the  flow  of 
events  among  components  (objects) .  In  other  words,  architectures  define  how  components 
communicate  by  means  of  events.  Finally,  the  similarity  of  one  architecture  to  another  is 
defined  by  a  mapping;  alternatively,  mappings  define  how  architectxures  are  related.  Fig¬ 
ures  5.16  and  5.17  are  object  models  for  the  component  2ind  the  architecture,  respectively. 
Figure  5.18  is  a  composite  of  all  the  architectural  components  of  /zRapide.  As  before,  the 
dashed  and  solid  lines  in  Figure  5.18  aid  in  discerning  the  different  relationships  in  the 
object  model. 

5.5.2  uRapide  Semantics.  Objects  that  exhibit  interesting  behavior  within 
/xRapide  are  the  component  and  architecture  objects.  These  are  the  architectural  items 
whose  semantics  are  anedyzed. 

5.5.2. 1  Component.  A  component’s  semantics  can  be  seen  in  Figure  5.19. 
Note  that  program  P  represents  the  execution  of  a  Method  identified  in  the  box.  $  can 
be  represented  as  the  following: 

{V alidEvent{InEventi)  A  ...  A  ValidEvent{InEventk))  A 

{{Attributei, . . . ,  AttributCn),  {Constrainti, . . . ,  Constraint,,,)}  G  ValidStateSpace 

’’ValidEvent”  is  a  predicate  that  ensures  that  an  InEvent  is  for  this  particular  com¬ 
ponent.  Also,  “VaJidStateSp2w:e”  is  the  cross  product  of  aU  the  legitimate  state  spaces  that 
a  component  can  occupy  based  on  the  vdues  of  its  Attributes,  as  restricted  by  the  Con¬ 
straints.  The  above  precondition  implies  that  the  InEvents  received  are  for  the  component 
and  the  state  space  for  a  component  is  defined  by  its  Attribute  values  and  Constraints. 

As  a  result  of  the  transformation  process  of  P,  ^  is  the  following: 
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Name 


Component 

Declaration 


Constraint 


Figure  5.16  /zRapide  Component  Object  Model 


Figure  5.17  ^Rapide  Architecture  Object  Model 


Figure  5.18  /iRapide  Complete  Object  Model 


(InEvcnii . . .  InEveni/^)  ^ 


w4«rt6ulei  . 

.  Atlribuit^ 

Conatrainij  . 

.  Conairainiyff 

^  [OulEventi  . .  .  OuiEvent^ 

Afelhodi . 

. .  Mtihodp 

Figure  5.19  Behavior  for  a  ^Rapide  Component 


Attributei  . . .  Attribute^ 


Constrainti . . .  Conatraintp 

(InEventi . . .  InEventk )  ^  =>  (OutEventi  . . .  OutEvent, ) 

Componenti . . .  Componentm 

Figure  5.20  Behavior  for  a  /xRapide  Architecture 

{Attribute'^, Attribute'^)  =  P{{Attributei, . . . ,  AttributCn), 

{InEventi , . . . ,  InEventk),  {Conatrainti , . . . ,  Conatraintm))  A 

{InEvent'i, InEvent'k)  =  P{{AttTibutei, . . . ,  Attributen), 

{InEventi InEventk )  i  {Conatrainti Conatraintm ) )  A 

{OutEvent'i, . . .  ,OutEvent'^)  =  P  {{ Attributei,. Attributen), 

{InEventi, InEventk),  {Conatrainti,. . . ,  Conatraintm)) 

The  postconditions  imply  that  as  a  result  of  performing  a  transformation,  the  com¬ 
ponent  may  have  changed  state.  The  chzmges  as  a  result  of  P  are  the  Attribute  values, 
the  InEvents,  and  the  OutEvents  of  a  component. 

5. 5. 2. 2  Architecture,  The  architecture’s  semantics  can  be  seen  in  Fig¬ 
ure  5.20.  Since  an  architecture  is  a  higher-level  abstraction  built  from  lower  level  abstrac¬ 
tions,  its  state  space  is  defined  by  its  local  Attributes  and  Components.  It  should  be  noted 
that  program  P  represents  some  subset  of  Methods  of  the  subordinate  components.  $  can 
be  represented  eis  the  following: 

{ValidEvent{InEventi)  A  ...  A  V alidEvent{InEventk))  A  {{Attributei,  ■  •  -,  Attributen) , 
{Componenti ,... ,  Componentm), 

{Conatrainti, . . ., Conatraintm)}  G  ValidState Space 

“ValidStateSpace”  for  an  architecture  is  the  cross  product  of  sJl  the  legitimate  state 
spaces  that  a  architecture  can  occupy  based  on  the  values  of  its  Attributes  and  its  sub¬ 
ordinate  Components,  as  restricted  by  the  Constraints.  The  above  precondition  requires 


that  the  InEvents  received  are  for  the  architecture  and  the  state  space  for  an  architecture 


is  defined  by  its  Attribute  values,  Components,  and  Constraints. 


After  the  transformation  process  of  P,  is: 

{Attribute^, . . . ,  Attribute'^)  =  P{{Attributei, . . . ,  AttributCn), 

{InEventi,. . .  ,InEventk),  {Constrainti, . . .  ,Constrainim))  A 

{Component'^ , . . . ,  Component'^)  =  P{{AttTibut€i, . . . ,  Attribute„), 

{InEventi,. . . ,  InEventk),  {Constrainti, . . .  ,Constraintm))  A 

{InEvent'i, . . . ,  InEvent',^)  =  P{{Attributei, . . . ,  AttributCn) , 

{InEventi,. . . ,  InEventk),  {Constrainti, . . .  ,Constraintm))  A 

{OutEvent'i, ...,  OutEventy)  =  P{{Attributei, ...,  Attributen), 

{InEventi,  •  •  ■  > InEventk),  {Constrainti,. . . , Constraintm)) 

The  postconditions  imply  that  as  a  result  of  performing  a  trauisformation,  the  archi¬ 
tecture  may  have  changed  state.  The  changes  as  a  result  of  P  are  the  Attribute  values, 
the  subordinate  Components,  the  InEvents,  and  the  OutEvents  of  a  Component. 


5.6  IBM  DSSA  Using  Batory’s  Layered  Approach 

5.6.1  Batory’s  Layered  Approach  Syntax.  The  object  diagram  for  Batory’s  Lay¬ 
ered  Approaw:h  is  shown  in  Figure  5.21. 

The  fundamental  unit  of  softwzire  construction  according  to  Batory  is  the  component. 
Each  component  h2is  an  interfaice  and  ein  implementation.  As  part  of  Batory’s  architec- 
turcd  model,  every  component  defined  must  belong  to  a  realm.  A  realm  contains  a  set  of 
components  with  the  same  interf2w:e,  but  different  implementations.  In  other  words,  every 
component  within  a  realm  inputs  the  same  type  of  information,  outputs  the  same  type  of 
information,  but  possibly  performs  a  different  transformation.  A  group  of  resdms  are  used 
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Transform 


Figure  5.21  IBM  DSSA  Software  Architectureil  Object  Model 


to  define  a  composition,  where  a  composition  is  a  set  of  guidelines  by  which  components 
are  glued  together  to  carry  out  a  mission. 

Components  input  information  of  a  particular  type  from  lower-level  components  and 
transform  it  to  a  type  the  next  higher-level  cein  use.  A  component  c£in  be  symmetric  or 
non-symmetric.  Symmetric  components  have  input  parameters  zmd  their  parameter  input 
type  is  the  same  eis  their  parameter  output  type.  Having  symmetric  components  within 
a  software  system  allows  for  arbitrary  stacking  of  components.  On  the  other  hand,  non- 
symmetric  components  have  input  parameters,  but  their  input  parameter  type  and  output 
parameter  type  do  not  match. 

There  are  three  ways  of  conceptually  understanding  components; 

1.  A  component  can  be  thought  of  as  a  layer,  where  a  software  system  is  a  stacking  of 

different  layers  (a  composition  of  components), 

2.  A  component  can  be  thought  of  as  a  function  that  is  invoked  to  provide  some  service. 

A  software  system  is  nothing  more  than  a  sequence  of  function  calls,  with  the  output 

of  one  function  providing  the  input  to  the  next  function. 

3.  “The  best  emalogy  for  reeilms  and  components  is  the  concept  of  a  grammar. 

A  component  corresponds  to  a  production.  Parameterized  components 
eure  productions  whose  right-heind  side  reference  nonterminals;  peirameter- 
less  components  are  productions  that  only  reference  terminals.  Symmetric 
components  correspond  to  recursive  productions” .  (6) 

5.6.2  Batory’s  Layered  Approach  Semantics.  Objects  that  exhibit  interesting  be¬ 
havior  within  Batory’s  Layered  Approach  2u:e  the  components  eind  software  system  (com¬ 
position)  objects.  These  £ire  the  architectural  items  whose  semantics  are  analyzed. 
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Attributei  . . .  Attribute^ 


{Inputi . . .  Input] )  =» 


=>  OutParameter, 


Transform 


Figure  5.22  Behavior  of  a  IBM  DSSA  Paurameterless  Component 


5.6.2. 1  Parameterless  Component.  A  parameter  less  component’s  semcintics 
cam  be  seen  in  Figure  5.22.  It  should  be  noted  that  program  P  is  the  Transform  identified 
in  the  box.  $  can  be  represented  as  the  following  list: 


{V alidlnput{lnputi)  A  ...  A  V alidlnput{lnputj))  A 
{Attributei] . . . ,  Attrihuten}  G  ValidStateSpace 

“Validinput”  is  a  predicate  that  evailuates  an  Input  and  ensures  that  the  input  value 
being  passed  to  the  component  is  of  a  type  the  component  can  input  and  within  boimds. 
AdditionaJly,  “ValidStateSpace”  represents  the  cross  product  of  all  the  legitimate  state 
spaces  that  a  component  can  occupy  based  on  its  Attribute  vedues.  The  precondition 
above  dictates  that  the  Input  values  are  of  the  correct  type  and  range,  and  the  values  of 
its  Attributes  form  a  valid  state  space  for  the  component. 

As  a  result  of  the  transformation  process  of  P,  ^  will  be  the  following: 

(Attribute'i ,... ,  Attribute'^)  =  P{  {Attributei Attribuie„) ,  (Inputi Input  j)) 

A 

OutParameter!^  =  P {{Attributei , . . . ,  Attribute„) ,  {Inputi, . . . ,  Inputj)) 

The  postcondition  of  a  component  i.’^dicates  that  the  component  as  a  whole  has 
changed  state  due  to  its  change  of  Attribute  values.  Also  changed  as  a  result  of  the 
transformation  process  P  is  the  OutPeirameter. 
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Attrtbutei  . . .  Attribute 


InParameter\  . . .  InParameter^  OutP arameter^ 

lYcuisform 

Figure  5.23  Behavior  of  a  IBM  DSSA  PEurameterized  Component 

5. 6.2. 2  Parameterized  Component.  The  pzirameterized  component’s  se- 
meintics  can  be  seen  in  Figmre  5.23.  It  should  be  noted  that  program  P  is  the  Transform 
identified  in  the  box.  $  can  be  represented  as  the  following; 

{ValidParameter{InParameteri)  A  ...  A  ValidParameter(InParameterk))  A 
{Attributei, . . . ,  Attributen}  €  ValidStateSpace 

“ValidParameter”  is  a  predicate  that  eveduates  an  InParameter  and  ensures  that  the 
InParameter  is  of  a  type  the  component  can  input.  As  with  the  parameterless  component, 
“ValidStateSpace”  represents  the  cross  product  of  all  the  legitimate  state  spaces  that  a 
component  cam  occupy  based  on  its  Attribute  values.  The  precondition  above  requires 
that  the  InPareuneters  eure  of  the  correct  type,  and  the  values  of  the  Attributes  form  a 
valid  state  space  for  the  component. 

As  a  result  of  the  trcinsformation  process  of  P,  ^  will  be  the  following; 

{Attribute'i, . . . ,  Attribute'^)  =  P{{Attributei, . . . ,  Attributen), 

(/ nParameteri ,...,/  nParameterk ) )  A 

OutParameter'i  =  P{(Attributei, . . . ,  Attributen) , 

{InParameteri ,...,  I  nParameterk)) 

The  postcondition  of  a  component  states  that  the  component  as  a  whole  heis  changed 
state  due  to  changes  in  the  Attribute  values.  Also  changed  as  a  result  of  the  transformation 
process  P  is  the  OutParameter. 
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{Input I  . . .  Input j )  ^ 


(Outputi  . . .  Output, ) 


Componenti . . .  Component,,, 

Figure  5.24  Behavior  of  a  IBM  DSSA  Software  System 

5.6.S.3  Software  System.  The  software  system’s  semantics  can  be  seen  in 
Figure  5.24.  It  should  be  noted  that  program  P  represents  to  transformation  of  amy  of  its 
subordinate  Components  in  the  box.  $  can  be  represented  as  the  following: 

{Validlnput{lnputi)  A  ...  A  ValidInput{Inputj))A 

{Componenti , . . .  ,Componentm}  G  V alidState Space 

“Validinput”  is  a  predicate  that  eveiluates  cm  Input  and  ensures  that  the  Input  is  of 
a  type  and  range  the  software  system  can  input.  “ValidStateSpace”  represents  the  cross 
product  of  all  the  legitimate  state  spaces  that  the  software  system  can  obtain  based  on 
the  state  spaces  of  its  subordinate  Components.  The  precondition  above  dictates  that  the 
Input  Values  are  of  the  correct  type  and  range,  and  the  state  space  of  its  Components  form 
a  valid  state  space  for  the  software  system. 

As  a  result  of  the  transformation  process  of  F,  will  be  the  following: 

{Component'i, . . .  ,Component'j^)  =  P{{Componenti, . . .  ,Componentm), 

{Inputi, . . .  ,Inputj))  A 

(Output'i, . . .  ,Output\)  =  P {{Componenti,. . .  ,Ccmponentn), 

{Inputi,  •  ■  • ,  Input  j)) 

The  postcondition  of  a  software  system  requires  that  the  software  system  as  a  has 
changed  state  due  to  state  changes  of  its  Components.  Also  changed  as  a  result  of  the 
transformation  process  P  is  the  Output  values. 
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5. 7  Analysis  of  Software  Architectures 

Each  section  of  this  chapter  analyzed  a  different  software  architecture  using  zui  object 
diagram  and  the  axiomatic  approach.  The  object  diagrcims  allow  the  comparison  of  the 
structmres  of  the  softweure  architectures  while  the  axiomatic  approach  allows  the  compEirison 
of  semantics  derived  from  the  state  space  of  the  objects,  as  constrained  by  preconditions 
and  postconditions. 

5.7.1  Structural  Analysis.  Table  5.1  is  a  composite  of  the  structur^J  components 
of  the  softwcire  architectures  that  can  be  identified  from  the  object  diagrams  eind  the 
documentation.  Characteristics  of  the  architectures  are  listed  on  the  left,  while  the  different 
architectures  are  listed  across  the  top  of  the  table. 

As  mentioned,  the  object  diagram  has  been  tailored  for  the  purposes  of  this  thesis 
effort.  As  such,  some  of  the  information  presented  in  Table  5.1  has  been  reintroduced  from 
the  literature. 

The  following  cm  be  drawn  from  analyzing  the  object  diagrams  of  the  softwme 
architectures: 

1.  All  architectural  components  have  some  way  to  retain  their  state  information.  In 
the  lowest-level  constructs,  the  state  information  is  retained  in  attributes;  in  higher- 
level  constructs,  state  information  is  captured  in  the  subordinate  objects,  as  well  as 
attributes. 
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Table  5.1  Structural  Commonalities  of  the  Software  Architectures 


Validation  Application  Application  Test 

Environment  Executive  Bend 


Events 


Event 

Management 


Event 

Buffers 


Lowest 

Abstraction 


Higher 

Abstractions 


Subsystem 


Process, 

Macro, 

Mode 


Attributes 
At  Lowest 
Level 


Attributes 
At  Higher 
Level 


Ways  to 
Change 
State 


Data  Ports 


State 


Update 

Algorithm, 

Operations 


Yes 


Implicit 


Source 

Modules, 

Paths 


Yes 


Implicit 


1  _ _  -1 

Test 

Bench 

1  M.  1 

Rapide- 1 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Entity/ 

Component 

Component 

Entity 

Component 

Yes 

Yes 

Yes 

Yes 

Operations 

Methods 

Yes 

Implicit 

Implicit 

Rapid 

Prototype 


Parameterless 

Component 


Parameterized 
Component, 
Configuration, 
Software  System 


Transforms 


Implicit 
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2.  All  components  of  the  different  architectures  have  a  way  to  change  state;  none  sure 
static.  Some  eirchitectures  use  operations  to  change  state,  some  use  an  update  algo¬ 
rithm  or  an  execution  path,  while  others  employ  a  transform. 

3.  All  of  the  architectures  incorporate  events  and  event  processing. 

4.  All  constructs  have  a  way  to  interface  with  their  environment.  Some  components  get 
their  information  from  inputs,  while  others  get  their  information  from  events. 

5.  All  the  softwcire  architectures  analyzed  employ  a  layered  architecture.  The  layered 
architecture  results  in  different  levels  of  abstractions,  with  the  higher-level  abstrac¬ 
tions  requesting  services  from  lower-level  abstractions. 

5.7.2  Semantics  Analysis.  Tables  5.2  and  5.3  are  composites  of  the  semantics  for 
the  most  primitive  objects  (of  interest)  and  the  higher-level  objects  of  interest  within  the 
aurchitectures,  respectively.  By  looking  at  each  of  the  two  categories  of  object  types  (most 
primitive  and  those  “built  on”  the  primitive  types),  we  can  see  that  there  are  differences 
within  eax:h  category.  As  ein  exeunple,  edl  the  primitive  type  objects  change  the  state  of 
their  associating  attributes  except  MetaH;  a  MetaH  Source  Entity  does  not  change  any  of 
its  local  attributes.  The  same  is  true  about  the  higher-level  objects  of  the  architectures; 
eill  change  the  state  of  their  local  attributes  (if  present)  except  MetaH. 

The  following  axe  some  general  conclusions  that  may  be  drawn  from  the  seman¬ 
tics  (preconditions  and  postconditions)  of  the  architectural  components  regardless,  of  the 
specific  software  architecture: 
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Table  5.2  Primitive  Objects  amd  Their  Semantics 


ItlSLil 

iSiSsffiai 

Objects  Tbftt 

Ckenge  State 

Itself 

Yes 

Yes 

Yes 

Yes 

Yes 

Attributes 

Yes 

Yes 

Yes 

Yes 

Output 

Yes 

Yes 

Yes 

Out  Events 

Yes 

Yes 

Yes 

Ye? 

Input 

Yes 

Yes 

In  Events 

Yes 

Yes 

^  Mentions,  but  gives  no  details. 


Table  5.3  Higher  Level  Abstractions  and  Their  Semantics 


Objects  That 

Change  State 

Itself 

Yes 

Yes 

Yes 

Yes 

Yes 

Local 

Attributes 

Yes 

Yes 

Yes 

Subordinate 

Objects 

Yes 

Yes 

Yes 

Yes 

Output 

Yes 

Yes 

Yes 

Out  Events 

Yes 

Yes 

Yes 

Yes 

Input 

Yes 

Yes 

In  Events 

Yes 

Yes 

Yes 

*  Mentions,  but  gives  no  details. 
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1.  The  lowest-level  constructs  modify  only  their  local  attributes  2uid  may  cause  some 
type  of  outputs  as  a  side  effect  of  the  transformation  process. 

2.  The  primitive  constructs  for  the  most  part  are  passive;  they  initiate  no  actions  on 
their  own  but  service  the  requests  of  higher-level  constructs. 

3.  The  higher-level  constructs  not  only  change  the  state  of  their  local  attributes  (if 
present)  and  possibly  cause  outputs,  but  may  also  force  the  change  of  state  of  their 
subordinate  objects. 

4.  The  higher-level  construct’s  state  is  a  composite  of  its  local  state  and  the  state  of  its 
subordinates. 

5.  An  object  at  a  particular  level  is  only  able  to  modify  the  state  of  objects  subordinate 
to  it;  it  is  not  able  to  cause  state  changes  to  other  objects  at  the  same  level  or  above 
in  the  architecture. 

5.8  Conclusions  From  Analysis 

As  mentioned  in  Section  5.7.1,  all  of  the  architectures  incorporate  the  layered  ap¬ 
proach  in  their  design.  An  advantage  of  employing  the  layered  approach  is  that  it  allows 
the  developer  of  a  system  to  abstract  a  component  to  the  desired  level.  The  developer  can 
model  an  object  at  the  lowest  level  or  model  the  object  as  several  subcomponents  intereict- 
ing  to  complete  a  t2isk  as  a  whole.  An  example  of  designing  different  levels  of  abstreictions 
for  the  same  object  can  be  seen  in  VHDL  and  OCU:  a  flip-flop  circuit  can  be  modelled  as 
a  single  object  or  may  be  built  from  lower-level  objects  such  as  nor  gates  or  nand  gates. 
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A  conunon  feature  of  all  of  these  architectural  modek  is  the  encapsulation  of  both 
the  local  state  and  information.  This  is  ticcomplished  via  the  layered  approach  eind  the  se¬ 
mantics  of  the  architectural  model.  The  layered  approach  allows  for  the  locedization  of  the 
information,  while  the  semantics  of  each  model  localizes  the  span  of  control.  The  localiza¬ 
tion  is  evident  in  the  semantics  of  the  2urchitectural  components  of  each  circhitecture;  each 
component  changes  its  loczJ  state  and  may  only  change  the  state  of  objects  subordinate 
to  it. 

There  is  no  one-to-one  mapping  of  components  between  software  architectures.  Al¬ 
though  the  components  of  two  architectures  may  appear  structurally  and  semzmtically 
similar,  they  cannot  be  directly  substituted  for  eawrh  other;  an  example  is  an  OCU  prim¬ 
itive  and  a  Met2iH  source  entity.  Both  have  ports  to  receive  data  from  amd  send  data 
through,  both  have  attributes,  and  both  are  almost  semantically  identical.  However,  the 
substitution  of  a  MetaH  source  entity  for  a  primitive  in  the  OCU  structure  would  fml.  The 
failure  czin  be  attributed  to  how  eewrh  of  these  components  change  state;  an  OCU  primitive 
ch2mges  state  by  executing  one  of  its  operations,  where  a  MetaH  source  entity  changes 
state  by  executing  one  of  its  source  modules. 

Another  point  that  can  be  drawn  from  the  analysis  of  these  software  architectural 
models  is  that  the  domain  knowledge  of  the  application  area  is  captured  in  the  most 
primitive  objects  of  the  architectures.  The  higher-level  abstractions  within  an  architecture 
have  less  domain  knowledge  of  the  application  area;  the  information  they  do  contmn  tends 
to  identify  their  span  of  control,  which  subordinate  objects  are  connected  together,  what 
resoiurces  are  shared,  and  how  they  are  to  accomplish  their  mission. 
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By  stepping  back  and  looking  over  the  information  presented  in  Tables  5.1,  5.2,  and 
5.3,  the  axchitectures,  their  components,  and  their  component’s  semantics  all  appear  sim¬ 
ilar.  From  a  structural  standpoint,  all  the  architecturad  components  have  ports  or  buffers 
to  receive  information,  attributes  to  store  information,  lowest-level  primitive  abstractions, 
amd  a  way  to  change  state.  From  a  semauitic  view,  aiU  the  axchitectiuraJ  components  be¬ 
have  the  same;  they  consume  input  or  in  events,  they  change  state,  and  they  produce  new 
output  or  out  events.  One  may  conclude  that  there  possibly  exists  a  meta-structure  (or 
meta-model)  for  software  architectures. 

Although  the  software  architecture  of  all  the  aurchitecturaJ  models  studied  in  this 
thesis  employ  the  layered  approach,  there  aure  some  conclusions  that  cam  be  drawn  from 
this  effort  that  point  to  some  necessary  chauracteristics  for  all  softwaire  airchitectures. 

1.  In  order  to  localize  the  effects  that  chamges  have  on  a  system  and  faicilitate  reuse 
within  any  architecture,  the  encapsulation  of  information  (information  hiding)  amd 
the  limiting  of  the  spam  of  control  of  an  architectmrad  entity  aire  good  criteria  for 
a  softwaire  architectinre.  Employing  these  two  concepts  ailone  minimizes  the  effects 
of  amy  chamges  on  a  system  whether  the  system  is  being  enhamced  (aidding  new 
capabilities  to  a  system)  or  maiintained. 

2.  By  limiting  the  span  of  control  amd  encapsulation  of  the  aurchitectural  entities,  the 
preconditions  and  postconditions  of  the  state  spaice  are  limited  as  well.  This  restrict¬ 
ing  of  the  preconditions  amd  postconditions  of  a  construct  makes  it  eaisier  to  replaice 
an  entity  within  one  airchitecture  with  an  entity  from  a  different  architecture  that 
conceptuailly  performs  the  saime  function  but  in  a  different  way.  This  leauis  to  the 
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possibility  of  reusing  design  and  domain  knowledge  from  other  projects  with  different 
eirchitectures. 

Just  as  the  characteristics  presented  above  (limitation  of  the  span  of  control  and 
the  encapsulation  of  information)  are  deemed  good  in  am  architecture,  the  laick  of  these 
characteristics  may  be  deemed  as  bad.  However,  at  present  there  does  not  exist  a  standard 
method  to  evaluate  an  architecture.  Other  areas  of  the  software  discipline  have  developed 
metrics  to  assess  the  code  complexity  (McCabe’s  Metrics),  adgorithms  efficiency  (O  and  a), 
and  test  coverage  (graph  theory).  It  cam  be  concluded  that  metrics  for  evaluating  software 
architectures  should  be  developed. 

FinaJly,  with  a  software  architecture  meta-model  and  a  metric  for  evailuating  softwaure 
architecttires,  the  capability  exists  to  map  a  component  of  one  aurchitecture  into  the  state 
spaice  of  amother  architecture.  The  metrics  cam  be  used  to  evaluate  a  software  aurchitecture 
from  which  am  entity  is  to  be  drawn.  The  results  of  applying  the  metric  cam  reveal  the 
eaise  of  removing  the  aurchitectural  component  while  adlowing  its  behavior  to  remaun  intaurt. 
Likewise,  the  meta-model  cam  be  used  to  identify  the  components  of  the  entity.  After 
retrieving  the  entity,  it  can  be  mapped  into  the  state  space  of  the  tairget  aurchitecture  based 
on  the  preconditions  and  postconditions  of  the  entity.  The  entity  cam  be  transformed 
without  the  loss  of  any  knowledge  by  using  a  state-spaice  transformation  process  ais  defined 
by  (11).  After  the  tramsformation  process,  the  new  entity  is  integrated  into  the  target 
architecture. 
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VI.  Detailed  Design  of  Architect's  Event- Driven  Simulation  Capability 


6. 1  Introduction 

As  presented  in  the  operational  concept  (Section  3.4),  events  in  Architect  are  passed 
to  an  independent  subsystem  by  the  executive.  Each  subordinate  subsystem  in  the  in¬ 
dependent  subsystem’s  structure  interrogates  the  event  after  the  event  is  received.  The 
interrogation  results  in  the  event  either  being  processed  by  the  subsystem  or  being  routed 
to  another  subordinate  subsystem.  The  following  sections  describe  the  implementation  of 
events  within  Architect  and  the  subsequent  modifications  required  to  Architect’s  behav¬ 
ioral  modeling  capabilities.  Additionally,  these  sections  describe  the  information  that  is 
encapsulated  in  the  events,  purposes  of  the  information  within  an  event,  and  changes  made 
to  the  subsystems  to  process  and  manage  events. 

6.1.1  Processing  of  Events.  Before  the  structure  of  the  events  could  be  defined, 
event  processing  for  Architect  needed  to  be  specified.  For  example,  questions  like  would 
subsystems  act  as  event  mwagers  with  the  primitives  processing  the  events,  or  should  the 
subsystems  both  process  and  manage  events  for  its  subordinate  primitives?  Keeping  with 
the  OCU  model  eis  defined  by  the  SEI,  subsystems  eure  the  “locus  of  the  mission”,  while 
primitives  sire  the  “services  to  carry  out  the  mission”  (14:18).  Since  the  subsystems  sire 
the  locus  of  the  mission,  I  opted  to  incorporate  event  processing  into  the  controller  of  the 
subsystem.  After  the  controller  interprets  an  event,  it  invokes  the  appropriate  subordinate 
object  to  carry  out  the  service  required.  Resolving  this  issue  allowed  the  identification  of 
the  tsurget  for  am  event  (a  primitive  of  a  subsystem)  and  a  routing  scheme  to  the  target. 
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6.1.2  Structure  of  Events.  As  mentioned  in  Chapter  3,  there  are  two  classes  of 
events  incorporated  within  the  Architect  system,  application  events  and  executive  events. 
The  following  information  was  identified  as  being  needed  by  all  event  types;  the  priority 
of  the  event,  the  event  time,  the  target  of  the  event  and  the  path  to  the  tcirget  (routing 
scheme)  through  the  subsystem  structures.  Figure  6.1  shows  the  information  common  to 
all  events.  The  ellipses  imply  that  an  event  may  contain  additional  information. 


BvAirb 

Routing 

Event 

Event 

TiJM 

SchoBW 

Prxor±i:y 

Target 

Figure  6.1  Common  Information  for  All  Events 


Further,  we  needed  to  identify  any  requirements  for  domain-specific  information  that 
needed  to  be  incorporated  into  any  of  the  events.  The  only  event  identified  needing  domain- 
specific  information  was  the  SetState  event.  The  SetState  event  contains  the  attribute 
names  and  Vcilues  that  need  to  be  chemged  for  a  peirticular  primitive  at  a  future  time. 
With  no  other  information  requirements  for  events,  the  application  events  were  defined  as: 


1.  Update  event  -  received  and  interpreted  by  a  subsystem.  The  target  is  a  primitive  of 
the  subsystem  that  receives  this  event.  The  receiving  subsystem  invokes  the  Update 
function  of  the  appropriate  primitive. 

2.  SetState  event  -  interpreted  by  a  subsystem  and  used  to  invoke  the  SetState  function 
of  the  appropriate  primitive. 
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3.  NewData  event  -  received  and  interpreted  only  by  the  superior  subsystem  in  an 
independent  subsystem.  The  superior  subsystem  schedules  Update  events  based  on 
ch£mges  to  any  data  in  its  import  area.  This  event  is  discussed  further  in  Section 
6.I.5.2. 

Figure  6.2  shows  the  events  listed  above  and  the  information  contained  in  each.  The 
underlines  emphasize  differences  between  the  NewData  and  Update  event 
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Figmre  6.2  Application  Events  With  Data  Types 


6.1.3  Event  Driven  Simulation  Within  Architect.  The  operationed  concept  for 
events  presented  in  Chapter  III  has  the  application  executive  passing  events  to  subsystems. 
This  is  considerably  different  from  the  sequential  flow  of  control  that  was  originally  designed 
in  (3,  20).  Subsystems  now  have  to  interpret  and  manage  events  in  the  event-driven 


simulation  instead  of  performing  a  set  of  operations  defined  in  an  update  algorithm.  The 


flow  of  control  for  the  event-driven  mode  is  still  sequentied  in  nature;  however,  events  are 
produced,  consumed,  routed,  received  and  mcmaged. 

6. 1.3.1  InEvent  and  OutEvent  Areas.  Data  flow  within  the  OCU  model  is 
managed  through  import  and  export  areas.  Since  the  SEI  nicikes  no  refe-t-nce  to  events 
or  event  processing  within  the  OCU  model,  a  mesins  to  pass  events  was  required.  Some 
of  the  jirchitectures  examined  under  this  thesis  separated  event  flow  from  data  flow  (25). 
Furthermore,  in  keeping  with  the  OCU  concept  of  arbitrary  compositions  of  subsystems  and 
primitives  to  form  me^ulingful  object  abstractions,  a  decision  was  made  not  to  incorporate 
events  into  the  import  and  export  areas.  Event  passing  is  implemented  in  much  the  same 
way  that  data  passing  is  implemented  in  the  OCU  model.  Events  flow  into  a  subsystem  via 
cin  InEvent  area  and  exit  the  subsystem  via  an  OutEvent  area.  These  additional  constructs 
enhanced  the  state  information  of  a  subsystem  by  allowing  the  events  of  a  subsystem  to  be 
persistent.  Since  event  information  is  ultimately  managed  by  the  application  executive’s 
event  meinager  (that  is,  a  subsystem  does  not  manipulate  an  event  unless  the  target  of 
the  event  is  itself  or  a  subordinate  primitive),  the  InEvent  and  OutEvent  areas  are  sets 
of  events  with  no  restrictions  on  the  number  or  ordering  of  events  within  these  areas. 
Under  this  effort,  the  InEvent  area  is  implemented  eis  a  sequence  of  events;  however,  since 
there  is  just  a  single  threEid  of  control  within  eui  independent  subsystem,  the  InEvent  area 
will  only  contain  one  event.  With  the  implementation  of  a  truly  concurrent  simulation 
mode,  more  than  one  event  may  be  present  in  the  InEvent  eurea.  However,  that  is  left  for 
future  research.  An  example  of  a  subsystem  with  LiEvent  and  OutEvent  areas  is  shown 
in  Figure  6.3. 
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Figure  6.3  Subsystem  With  InEvent  and  OutEvent  Areas 


6. 1.3.2  Flow  of  Events  Through  Subsystems.  Section  6.1.1  indicated  that 
the  target  of  an  event  is  usually  a  primitive  object.  The  parent  subsystem  of  the  target 
primitive  actually  “decodes”  the  event  and  invokes  the  appropriate  primitive’s  function 
as  defined  by  the  event  type.  The  routing  scheme  of  the  event  contains  a  sequence  of 
subsystems  that  are  superior  to  the  primitive.  Figure  6.4  shows  a  subsystem  structure  and 
a  sample  event  targeted  for  a  subordinate  primitive;  emphasized  are  the  target  and  routing 
scheme  fields  of  the  event.  The  routing  scheme  within  an  event  can  be  thought  of  as  a 
directory  to  the  primitive.  Since  the  overzdl  structure  of  the  OCU  model  is  hierarchical 
and  the  subsystems  are  only  aware  of  subordinate  objects  directly  beneath  it,  a  subsystem 
must  be  able  to  query  the  event  as  to  whether  it  needs  to  process  or  route  the  event.  This 
querying  is  accomplished  by  the  subsystem  removing  its  name  from  the  routing  scheme.  If 
there  are  any  subsystems  remaining  in  the  routing  scheme,  then  a  subsystem  routes  this 
event  to  a  subordinate  subsystem,  as  specified  by  the  next  name  in  the  routing  scheme. 
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However,  if  the  routing  scheme  is  empty,  the  subsystem  consumes  the  event  and  invokes 
one  of  its  primitive’s  operations. 


Figure  6.4  Sample  Subsystem  with  Associated  Event  Targeted  For  Primitive 


6. 1.3.3  Changes  to  Execution  Functions  of  Architect.  This  processing  eind 
managing  of  events  forced  Architect  to  have  two  EXECUTE  functions.  One  EXECUTE 
function  is  the  original  simxilation  capability  as  implemented  by  (3,  20).  The  new  EXE¬ 
CUTE  function  had  to  know  of  the  InEvent  and  OutEvent  areas  of  subsystems  and  the 
structme  of  the  events.  Additionally,  the  controller  of  a  subsystem  is  no  longer  concerned 


with  8«i  Update  Algorithm  as  the  events  received  dictates  the  actions  of  the  subsystem. 
The  new  execute  function  had  to  be  capable  of  passing  events  down  to  subsystems  emd 
receiving  events  from  lower  level  subsystems  and  primitives.  This  required  a  rewrite  of  the 
following  Architect  functions: 

1.  Execute-Subsystem  -  This  function  checks  the  subsystem’s  execution  mode  and  either 
invokes  the  sequential  mode  as  implemented  by  (3,  20)  or  invokes  the  Event-Driven- 
Controller. 

2.  Set-Export  -  This  function  checks  the  execution  mode  and  either  operates  ais  it  did 
under  the  sequential  mode  or  returns  a  set  of  events. 

3.  Update  -  This  function  invokes  the  primitive  objects  update  algorithm  as  it  did  under 
the  sequential  mode,  but  ss  a  result  of  an  event-driven  execution,  it  returns  a  SetState 
event.  This  is  determined  by  the  domain  implemented  by  the  domain  engineer. 

4.  SetState  -  Again,  depending  on  the  mode,  this  function  works  as  it  always  did  or 
returns  a  set  of  events. 

Not  only  did  some  of  Architect’s  origined  functions  need  to  be  rewritten,  but  some  new 
functions  had  to  be  added  to  generate  events: 

1.  Event-Driven-Controller  -  queries  events  of  a  subsystem  to  determine  if  this  subsys¬ 
tem  should  process  the  event  or  route  it  to  a  subordinate  subsystem. 

2.  Gen-Set-State-Event  -  generates  a  SetState  event  for  a  primitive. 

3.  Gen-Update-Event  -  generates  ^ln  Update  event  for  a  primitive. 
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4.  Gen-Transmit-Event  -  generates  a  Transmit  event  for  the  executive  informing  the 
executive  some  exports  have  changed. 

5.  Gen-Remove-Event  -  generates  a  Remove  event  for  the  executive  informing  the  ex¬ 
ecutive  that  a  primitive  wants  to  discard  a  previously  generated  event. 

6.  Eliminate-Dupes  -  reduces  event  handling  overhead  by  reviewing  all  events  received 
and  eliminating  redundant  events  based  on  the  target  and  time  fields  within  the 
event. 

All  of  these  functions  are  invoked  when  the  event-driven  EXECUTE-SUBSYSTEM  func¬ 
tion  is  invoked  and  the  simulation  mode  is  event-driven. 

6.1.4  Changes  to  the  Semantic  Checks.  With  the  inclusion  of  the  event-driven 
simulation,  the  semantic  checks  were  changed.  A  majority  of  the  semantic  checks  are  still 
valid  emd  required.  However,  depending  on  the  simulation  mode,  checks  that  validate  the 
Update  algorithm  within  a  controller  of  a  subsystem  may  or  may  not  be  -equired.  Under 
the  event-driven  simulation,  the  presence  of  ^ln  Update  edgorithm  i  -^al.  Conversely, 
imder  the  sequential  mode,  the  Update  algorithm  is  mandatory. 

Also,  since  multiple  independent  subsystems  are  possible,  the  semantic  checks  that 
validate  the  import  and  export  connections  for  data  communication  needed  modification. 
Imports  and  exports  within  an  independent  subsystem  are  connected  via  source  objects 
emd  target  objects.  These  source  and  target  are  converses  that  identify  either  the  export 
source  that  produces  the  information  for  this  import  or  the  import  target  that  consumes 
the  information  from  this  export.  With  the  implementation  of  the  application  executive,  a 
connection  object  is  now  VEtlid  between  the  imports  and  exports  in  addition  to  the  source 
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and  target  objects.  A  connection  object  serves  the  same  purpose  as  the  source  and  target 
objects;  however,  a  connection  object  connects  the  imports  and  exports  of  independent 
subsystems.  For  a  detailed  description  of  the  connection  object  see  (29).  Figure  6.5  shows 
the  relationships  of  source,  target  and  connection  objects. 


Figure  6.5  Two  Independent  Subsystems  showing  the  Relationships  of  Source,  Target 
and  Connection  Objects 

6.1,5  Consolidation  of  Import  Areas  and  Export  Areas.  As  a  result  of  the  im¬ 
plementation  of  the  application  executive  functions  within  Architect  (29),  Architect  must 
be  capable  of  handling  multiple  independent  subsystems.  Not  only  is  it  possible  for  the 
application  speci2ilist  to  generate  subsystems  for  the  application  being  designed,  but  he  cam 
also  generate  executive  subsystems  eis  well.  Since  the  executive  subsystems  are  essentially 
independent  of  the  application  subsystems,  there  does  not  exist  a  parent-child  relationship 
between  these  two  subsystems.  An  application  subsystem  and  an  executive  subsystem  axe 
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independent  subsystems  that  communicate;  they  we  essential  to  modeling  the  behavior  of 
an  application,  but  neither  is  subordinate  to  the  other. 


Application  Subsystem  Executive  Subsystem 


Figure  6.6  Independent  Subsystems  Represented  as  an  Executive  Subsystem  and  an  Ap¬ 
plication  Subsystem 


6. 1,5.1  Relocation  of  Import  and  Export  Areas.  These  independent  subsys¬ 
tems  forced  a  chemge  to  the  originzd  implementation  of  the  import  areeis  and  export  areas. 
As  originally  implemented,  import  zmd  export  areas  were  associated  with  each  subsystem 
at  each  level  of  a  subsystem’s  hierarchy  (see  Figure  6.7).  This  worked  fine  when  compos¬ 
ing  an  application  consisting  of  a  single  independent  subsystem;  however,  with  multiple 
independent  subsystems,  this  implementation  was  no  longer  feasible.  Allowing  multiple 
independent  subsystems  to  connect  to  subordinate  subsystems  of  other  independent  sub¬ 
systems  obligated  subsystems  to  know  more  about  their  environment  than  intended  by 
the  SEI  (14:18).  The  OCU  model  was  designed  so  that  each  level  of  abstreurtion  within 
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a  subsystem  only  knew  of  its  immediate  subordinate  objects.  To  resolve  the  contention, 
the  import  areas  and  export  areas  were  consolidated  at  the  highest-level  subsystem  in  an 
independent  subsystem,  thus  limiting  the  knowledge  level  of  the  lower-level  subsystems 
and  primitives.  Figure  6.6  above  shows  how  the  imports  and  exports  have  been  consol¬ 
idated  at  the  highest-level  subsystem  in  zm  independent  subsystem.  This  is  strictly  an 
implementation  detail;  conceptuedly,  the  imports  and  exports  are  the  same  as  the  SEI 
intended. 


Figure  6.7  Original  Import  Export  Implementation 


6. 1.5.2  New  Information  in  the  Imports  and  Exports.  Since  the  import  area 
and  export  zurea  are  at  the  highest-level  subsystem,  only  the  appropriate  subsystem  and 
primitive  can  be  allowed  to  access  its  import  or  export  data.  This  was  eiccomplished  by 
adding  the  owning  subsystem  information  to  the  import  eind  export  areas  and  partitioning 
the  import  and  export  eureas. 


Further,  a  decision  was  made  that  the  highest-level  subsystem  manages  access  to  all 
the  imports  and  exports  of  all  of  its  subordinate  primitives.  This  management  was  required 
since  the  executive  could  now  change  the  data  in  an  import  area  as  a  result  of  some  type  of 
communication  from  another  independent  subsystem.  When  the  data  of  an  import  area  is 
changed,  the  executive  informs  the  highest-level  subsystem  of  an  independent  subsystem 
of  the  new  data  via  a  NewData  event.  Reception  of  a  NewData  event  signals  the  highest- 
level  subsystem  that  some  other  independent  subsystem  has  communicated  with  it,  and  it 
needs  to  schedule  some  events  based  on  the  new  data  in  its  import  area.  The  highest-level 
subsystem  only  schedules  update  events;  it  collects  the  information  needed  to  build  the 
update  events  directly  from  the  information  present  in  its  import  area.  In  keeping  with 
the  SEI’s  intentions  of  anonymity  of  subsystems,  the  information  required  to  generate  an 
update  event  had  to  be  moved  to  the  import  area.  The  knowledge  of  a  subsystem  is  still 
limited,  since  a  highest-level  subsystem  does  not  explicitly  know  of  any  subordinate  objects 
more  than  one  level  beneath  it.  The  information  required  is  present  in  the  import  area; 
it  is  the  routing  scheme  needed  to  help  route  an  event  to  its  intended  target.  Figmres  6.8 
shows  a  Scunple  subsystem  structure,  and  Figure  6.9  shows  the  information  contained  as 
part  of  the  imports  and  exports  of  the  subsystem,  respectively. 

6.2  Conclusion 

This  chapter  presented  ein  overview  of  the  detailed  design  of  incorporating  event 
processing  and  management  into  Architect.  Since  Architect  was  designed  around  the 
OCU  software  architectural  model,  the  inclusion  of  an  event  processing  capability  had 
to  conform  to  the  intent  and  spirit  of  the  OCU  model  as  defined  by  the  SEI  (14).  All 


Figure  6.8  Sample  Subsystem 


decisions  involving  event  processing  have  been  presented  in  this  chapter.  The  next  chapter 
shows  the  applications  used  to  validate  the  changes  to  the  import  and  export  areas  emd 
the  applications  used  to  verify  the  event-driven  simulation  capability.  All  the  changes  were 
validated  using  domains  available  as  a  result  of  other  research  efforts  (26,  27). 
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Figure  6.9  Sample  Import/Export  Information  and  Data 


6-14 


VII.  Validation  of  Architect’s  Event- Driven  Capability 

7. 1  Introduction 

The  event-driven  capability  of  Architect  was  validated  in  multiple  phases.  One  phase 
of  the  validation  was  done  using  the  primitives  implemented  as  part  of  the  original  circuits 
domain  (3,  20);  the  other  phase  of  vzdidation  was  done  using  the  application  executive 
implemented  by  (29)  and  the  new  domains  incorporated  by  (26).  A  multi-phase  approach 
was  the  result  of  the  development  time  of  the  application  executive  and  the  development 
time  of  the  new  domains.  Since  the  consolidation  of  imports  and  exports  to  the  highest- 
level  subsystem  was  accomplished  independently  of  the  implementation  of  the  event-driven 
capability,  these  changes  were  also  V2ilidated  independently.  As  more  of  the  event-driven 
capability  was  realized,  incremental  validation  was  performed  to  validate  this  new  capa¬ 
bility.  The  rest  of  this  chapter  discusses  the  results  of  the  validation. 

7.2  Consolidation  of  Import  and  Export  Areas 

The  v2didation  of  the  consolidated  import  and  export  eureas  was  completed  using  the 
original  gate  primitives  developed  by  (3,  20).  Two  scenarios  for  validation  were  performed, 
one  using  a  single  independent  subsystem  and  the  other  using  multiple  independent  sub¬ 
systems. 

7.2.1  Single  Independent  Subsystem.  This  validation  scenzurio  consisted  of  two 
different  circuits.  The  first  circuit  was  a  simple  design,  as  seen  in  Figure  7.1;  Figure 

7.2  shows  some  of  the  multiple  configurations  this  circuit  may  have  using  subsystems  ^lnd 
primitives.  The  truth-table  for  the  simple  circuit  is  shown  in  Table  7.1.  This  circuit  helped 
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Figure  7.1  Simple  Circuit  for  Independent  Subsystem 
Table  7.1  Truth-Table  of  Single  Independent  Circuit 


Switch 

LED 

0 

Off 

1 

On 

by  initially  focusing  on  the  complex  interactions  of  a  few  subsystems  eind  primitives,  and 
their  respective  imports  and  exports  vice  the  large  volume  of  interactions  in  a  more  complex 
structure. 


The  next  circuit  used  to  test  the  import/export  consolidation  was  more  ambitious. 
The  circuit  was  a  binary  array  multiplier  emd  is  shown  in  Figure  7.3.  The  configuration  of 
the  subsystems  and  primitives  for  the  binary  array  multiplier  may  be  seen  in  Figure  7.4 
zmd  the  truth  table  is  in  Table  7.2. 

1.2.Z  Multiple  Independent  Subsystems.  Since  Architect  was  soon  to  have  mul¬ 
tiple  independent  subsystems  as  part  of  an  application,  this  validation  included  a  circuit 
that  passed  information  between  two  independent  subsystems.  The  circuit  chosen  was  the 
same  circuit  used  in  Figure  7.1,  but  its  implementation  was  chainged  as  illustrated  in  Figure 
7.5. 
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Figure  7.2  Simple  Circuit  as  an  Architect  Implementation 
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Pigvire  7.5  Architect  Implementation  of  Simple  Circuit  with  Independent  Subsystems 


7.5  Initial  Validation  of  the  Event- Driven  Capability 

Due  to  the  timing  of  the  development  of  the  application  executive  and  the  new 
domun,  the  event-driven  capability  was  initially  tested  using  four  primitives  from  the 
new  domain  and  a  prototype  application  executive  stub.  This  prototype  executive  was 
nothing  more  than  a  pseudo  application  executive  to  provide  an  event  manager  capability 
to  simulate  the  behavior  of  the  application,  since  the  application  executive  being  developed 
as  part  of  (29)  was  not  ready  for  validation.  The  initial  set  of  primitives  provided  by 
the  circuits  event-driven  domain  were  a  switch,  or  gate,  and  gate,  and  LED.  With  the 
initially  limited  capabilities  of  the  validation  software,  the  first  circuits  used  for  event- 
driven  validation  were  rudimenteuy.  However,  this  independent  validation  allowed  for 
loose  coupling  between  the  forthcoming  application  executive  and  the  event  processing 
capabilities  of  subsystems. 

7.3.1  Single  Independent  Subsystem.  The  single  independent  circuit  to  test  the 
event-driven  capability  was  ageun  the  simple  circtiit  use  in  Figme  7.1.  The  proposed  events 
that  needed  to  be  generated  and  consumed  as  a  result  of  simulating  the  circuit  are  shown  in 
Table  7.3.  The  events  in  the  table  are  in  the  order  that  they  are  generated  and  consumed. 
Thus,  an  Update  event  for  And  is  generated  before  the  Transmit  event  is  (a  Transmit  event 
is  an  executive  event  and  is  discussed  in  (29)).  Likewise,  the  Update  event  is  consiuned 
before  the  Tramsmit  event  is.  The  data  imder  the  “Information  for  Executive”  field  is 
data  required  by  the  application  executive  but  not  used  by  the  “mock-up”  executive.  The 
SetState  event  above  the  double  line  is  obtained  from  the  application  specialist  diming  the 
application  definition  process;  it  was  not  generated  as  part  of  the  event-driven  simulation. 


7-6 


Table  7.3  Events  smd  Their  Order  for  Single  Independent  Subsystem 


Event  Type 

Target 

Information  for  Executive 

SetState 

Switch 

Update 

Transmit 

SetState 

Update 

Transmit 

SetState 

And 

And 

LED 

LED 

Out  1,  Switch 

Out  1,  And 

Table  7.4  Events  and  Their  Order  for  Multiple  Independent  Subsystems 


Event  Type 

Target 

Information  for  Executive 

SetState 

Switch 

Update 

Transmit 

SetState 

Transmit 

NewData 

Update 

SetState 

And 

And 

Subsy8tem2 

LED 

LED 

Out  1,  Switch 

Out  1,  And 

7.5.2  Multiple  Independent  Subsystems.  The  multiple  independent  circmt  to  test 
the  event-driven  capability  was  the  same  circmt  presented  in  Section  7.3.1  but  implemented 
in  Architect  as  Figure  7.5.  The  proposed  events  that  needed  to  be  generated  and  consumed 
as  a  result  of  simxilating  the  circuit  are  shown  in  Table  7.4.  As  before,  the  SetState  event 
above  the  double  line  is  obtmned  from  the  application  specialist  dm-ing  the  application 
definition  process;  it  was  not  generated  eis  part  of  the  event-driven  simulation. 


7.4  Final  Validation  of  the  Event-Driven  Capability 

7.4.1  Single  Independent  Subsystem.  The  single  independent  circuit  to  test 
the  fined  event-driven  capability  is  shown  in  Figure  7.6  and  its  corresponding  Architect 
implementation  in  Figure  7.7.  The  truth-table  is  contained  in  Table  7.5,  and  the  proposed 
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Figure  7.6  Simple  Circuit  for  Event-Driven  Validation 


Table  7.5  Truth-Table  of  Simple  Circuit  for  Initial  Event-Driven  Validation 


Switch  2 

Switch  1 

Led 

0 

0 

On 

0 

1 

On 

1 

0 

On 

1 

1 

Off 

events  and  their  order  for  generation  and  consumption  as  a  result  of  simulating  the  circuit 
are  shown  in  Table  7.6.  Once  again,  the  SetState  events  above  the  double  line  are  input 
as  part  of  the  application  definition  process,  they  were  not  generated  as  part  of  the  event- 
driven  simulation. 

Multiple  Independent  Subsystems.  The  multiple  independent  circuit  to 
test  the  final  event-driven  capability  was  not  much  more  involved  than  the  circuit  in  Sec¬ 
tion  7.4.1,  smd  it  is  shown  in  Figure  7.8.  However,  the  Architect  implementation  of  the 
circuit  was  much  more  involved,  as  shown  in  Figure  7.9.  The  truth-table  for  the  circuit  in 
Figure  7.6  is  contained  in  Table  7.7.  The  proposed  events  and  their  order  of  consumption 
as  a  result  of  simulating  the  circuit  zure  contained  in  Table  7.8.  The  SetState  events  above 
the  double  line  are  obtained  from  the  application  specialist  as  part  of  the  application  defi¬ 
nition.  Since  there  zure  multiple  independent  subsystems  in  this  simulation,  the  ordering  of 
the  generation  of  events  may  vary;  however,  what  is  important  is  the  fact  that  the  events 
were  generated  emd  the  events  were  consumed  in  the  proper  order.  The  lines  separating 


Figure  7.7  Simple  Circuit  for  Event-Driven  Validation  in  Architect 


Table  7.6  Events  and  Their  Order  For  Fin^d  Simple  Circmt  Validation 


Figure  7.8  Enhanced  Circuit  for  Event-Driven  Validation 


Figvire  7.9  Enhanced  Circuit  for  Event-Driven  Validation  in  Architect 


the  events  show  what  events  occur  together  or  at  a  singxe  point  in  time.  As  an  example, 
the  first  five  events  after  the  double  line  are  executed  at  a  single  point  in  time  during  the 
simulation;  the  next  three  events  occur  at  some  future  point  of  time  in  the  simulation. 

7.5  Conclusions 

The  multi-phase  approach  for  validation  emd  verification  of  Architect’s  new  capabil¬ 
ities  proved  beneficial  for  several  reasons: 
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Table  7.7  Truth-Table  for  Enhanced  Circuit  Validation 


Table  7.8  Events  and  Their  Order  For  Final  Enhanced  Circuit  Validation 


Event  Type  |  Target 


Information  for  Executive 


SetState 

Switch  1 

SetState 

Switch  2 

SetState 

Switch  3 

Update 

IVansmit 

And  1 

Tiransuiit 

Update 

TVansmit 

And  2 

SetState 

And  1 

Transmit 

SetState 

And  2 

NewData 

Update 

Subsystem  3 
And  2 

SetState 

And  2 

Update 

Transmit 

Not 

SetState 

Not 

Update 

Transmit 

LED 

SetState 

LED 

Out  1,  Switch  1 
Out  1,  Switch  2 

Out  1,  Switch  3 


Out  1,  And  1 


1.  The  initial  phase  allowed  for  the  overlap  of  different  development  efforts  for  the  new 


domains,  application  executive,  and  event-driven  simulation  capabilities  (29,  26). 

2.  The  initial  pheise  of  moving  the  import /export  areais  was  completed  prior  to  any 
of  the  other  efforts;  as  such,  the  code  was  used  as  the  baseline  for  the  application 
executive  and  the  development  of  new  domain  primitives. 

3.  The  application  “mock-up”  and  new  domain  primitives  resulted  in  the  event-driven 
capabilities  for  Architect  being  available  prior  to  full  implementation  of  the  applica¬ 
tion  executive.  Again,  this  code  was  used  as  a  baseline  for  further  development. 

4.  The  small  increments  of  changes  resulted  in  focusing  on  the  task  at  hand.  Errors 
could  be  isolated  and  repmred  quickly  by  being  able  to  identify  what  code  had  in¬ 
troduced  the  error. 

5.  The  small  increments  also  resulted  in  a  staged  development.  As  each  phase  of  de¬ 
velopment  was  validated,  the  next  phase  was  developed  using  previously  developed 
tools  or  functions. 

6.  Lastly,  during  final  integration  of  the  event-driven  capability,  application  executive 
and  new  domains,  errors  were  qmckly  isolated. 
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VIII.  Conclusions  and  Recommendations 


8. 1  Summary  of  This  Research 

The  primsury  purpose  of  this  research  was  to  develop  a  framework  for  comparing 
software  architectures.  The  framework  had  to  be  capable  of  capturing  the  s2Llient  points 
of  a  software  architecture  and  being  applied  to  several  jirchitectures  without  tailoring. 

A  secondary  eflfort  was  to  modify  the  simulation  capability  of  a  prototype  domain- 
oriented  application  composition  system  called  Architect,  to  include  events,  event  handling, 
and  event  management. 

8.1,1  Framework  for  Comparing  Software  Architectures.  The  primary  purpose 
for  developing  a  framework  for  comparing  software  zurchitectures  was  to  evaluate  the  OCU 
model  for  its  suitability  as  a  software  architectinrad  model  for  application  composition  and 
generation  systems.  A  secondary  purpose  was  to  identify  potential  sources  for  design  reuse. 
The  design  reuse  may  be  at  the  component  (model)  level  or  may  be  a  higher  abstraction 
such  as  an  architectural  entity.  By  comparing  the  components,  architectural  fragments,  and 
the  Mchitectures  as  a  whole,  the  simileirities  and  differences  of  the  structure,  information, 
and  semantics  become  evident  and  crm  be  identified.  These  similarities  and  differences 
of  architectur2d  entities  can  ultimately  lead  to  a  mapping  between  eirchitectures  and  their 
components. 

The  scope  for  developing  the  framework  for  comparing  software  zurchitectures  was 
limited  to  developing  object  diagreuns  to  show  the  syntax  (structure)  of  an  architecture. 
Also,  the  scope  included  using  the  axiomatic  approach  to  show  the  semantics  (behavior) 
of  an  architecture’s  components  identified  in  the  object  diagram.  The  axiomatic  approach 
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includes  the  definition  of  ein  abstract  program  P  that  maps  the  state  space  of  some  archi¬ 
tect  urzd  entity  to  another  state  space. 

8.1.2  Specific  Conclusions  About  Software  Architectures.  The  fraunework  identi¬ 
fied  above  waus  used  to  analyze  the  software  architectures  of  VHDL,  MetaH,  pRapide,  IBM 
ADAGE  and  OCU.  The  results  of  the  structural  analysis  of  the  2irchitectures  revealed: 

1.  All  architectural  components  have  some  way  to  ret^n  their  state  information.  In 
the  lowest-level  constructs,  the  state  information  is  retained  in  attributes;  in  higher- 
level  constructs,  state  information  is  captured  in  the  subordinate  objects,  eis  well  as 
attributes. 

2.  All  components  of  the  different  architectures  have  a  way  to  change  state;  none  are 
static.  Some  architectures  use  operations  to  change  state,  some  use  an  update  algo¬ 
rithm  or  an  execution  path,  while  others  employ  a  transform. 

3.  All  of  the  architectures  incorporate  events  and  event  processing. 

4.  All  constructs  have  a  way  to  interface  with  their  environment.  Some  components  get 
their  information  from  inputs,  while  others  get  their  information  from  events. 

5.  All  the  software  architectures  anedyzed  employ  a  layered  architecture.  The  layered 
architecture  resxUts  in  different  levels  of  abstractions,  with  the  higher-level  abstrac¬ 
tions  requesting  services  from  lower-level  abstractions. 

A  semantic  comparison  of  the  software  architectures  revealed  the  following: 
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1.  There  does  not  exist  a  one-to-one  equivalence  between  any  of  the  axchitectxuraJ  entities 
Eonong  the  zurchitect\ires.  The  trcinsformation  process  P  performs  the  transformation 
from  state  space  to  state  space  differently  for  the  components  of  each  architecture. 

2.  The  lowest-level  constructs  of  an  architecture  only  change  the  state  of  their  local 
attributes  and  output  values. 

3.  The  lowest-level  constructs  are  passive  or  reactive  in  nature. 

4.  Architectural  entities  composed  of  lower-level  constructs  change  state  based  on  the 
state  changes  in  their  subordinate  constructs.  If  an  entity  has  any  local  state  infor¬ 
mation,  this  local  information  changes  as  a  result  of  a  transformation.  Each  level 
of  abstraction  within  an  architecture  is  only  able  to  modify  the  state  of  components 
directly  subordinate.  In  effect,  the  scope  of  change  is  limited  to  one  level  at  a  time. 

8.2  General  Conclusions  About  Software  Architectures 

The  framework  developed  as  pzurt  of  this  thesis  effort  had  some  strong  points  and  some 
weak  points.  The  strong  points  are  that  the  architectural  entities  of  a  software  architecture 
are  readily  evident  as  a  result  of  the  object  diagram,  and  the  variants  and  invariants  of 
an  entity  are  evident  as  a  result  of  the  sem2intics  presented  using  the  axiomatic  approeu:h. 
This  framework  showed  that  semanticeilly  and  syntactically  there  was  no  direct  mapping 
between  architectural  entities  of  different  architectures.  However,  the  framework  highlights 
the  variant  information  of  an  entity.  If  my  type  of  transformation  is  to  be  possible,  the 
information  and  behavior  of  an  entity  identified  by  this  framework  must  be  preserved  as  a 
residt  of  a  transformation. 
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Also,  this  framework  highlighted  that  several  common  elements  seem  to  be  included 
in  all  the  software  architecttires.  The  common  elements  identified  in  this  resetirch  effort 
may  possibly  lead  to  the  development  of  a  meta-model  for  software  architectures. 

Finally,  the  framework  characterized  some  aspects  (or  properties)  of  architectures 
that  are  desirable.  While  no  metrics  currently  exist  for  evaluating  software  architectures, 
this  resezurch  is  an  initial  step  in  identifying  architectural  properties  and  corresponding 
metrics  for  characterizing  software  architectures. 

A  weak  point  of  this  research  is  that  it  does  not  give  any  insight  into  the  development 
of  the  abstract  program  P  for  the  axiomatic  approach.  It  does  present  the  precondition 
on  the  state  space  of  an  entity  and  the  postcondition  that  need  to  be  mmntmned  on  the 
variants  as  a  result  of  the  state-space  transformation  process  of  P,  but  it  does  not  provide 
details  of  how  to  derive  P. 

As  a  result  of  developing  the  framework  for  comparing  the  architectures  and  perform¬ 
ing  the  comparisons  of  the  veuious  software  architectures,  it  can  be  concluded  that  the  OCU 
model  has  all  the  elements  necessary  to  allow  Architect  to  mature  into  a  domain-oriented 
application  composition  and  generation  system  that  is  able  to  accept  system  specifications 
from  an  application  specialist  and  produce  verifiable  software.  The  syntax  is  similar  to 
other  successful  software  architectures  and  the  semantics  are  comparable  to  all  the  other 
architectures  as  well. 

8.2.1  Incorporation  of  Event  Driven  Capability  into  Architect.  A  need  to  in¬ 
corporate  event  management,  heindling,  and  processing  into  Architect  was  identified  by 
previous  research  efforts.  Since  the  initial  implementation  of  Architect  employs  the  OCU 


architectural  model,  the  inclusion  of  events  and  the  eissociated  processing  requirements 
had  to  conform  to  the  OCU  model  as  specified  by  the  SEI.  However,  SEI  documentation 
on  the  OCU  model  makes  no  mention  of  events  or  event  processing.  Therefore,  I  had  to 
extrapolate  the  intended  meaning  of  the  OCU  model  for  the  inclusion  of  events.  The  scope 
of  this  work  was  limited  to  designing  the  event  management,  processing,  amd  handling  ca¬ 
pabilities  of  the  subsystems  and  primitives  within  Architect.  The  operating  environment 
of  the  application  executive  was  eiddressed  in  a  separate  effort. 

The  following  was  accomplished  as  a  result  of  incorporating  events  into  Architect: 

1.  The  type  of  events  and  their  corresponding  formats  were  identified  and  implemented 
within  the  circhitecture  of  the  OCU  model. 

2.  Event  persistence  was  accomplished  via  the  InEvent  aind  Out  Event  areas  attached 
to  each  subsystem. 

3.  In  keeping  with  the  OCU  spirit  as  intended  by  the  SEI,  subsystems  consume  events, 
as  this  falls  in  the  purview  of  “locus  of  mission”.  After  consuming  the  event,  a 
subsystem  invokes  a  primitive  to  supply  the  service  intended  by  the  event. 

4.  The  flow  of  events  through  the  subsystem  structure  was  identified.  Subsystems 
needed  to  be  able  to  interrogate  events  to  determine  the  event’s  target.  After  deter¬ 
mining  the  event’s  target,  a  subsystem  processes  the  event  or  routes  it  to  a  subordi¬ 
nate  subsystem. 

5.  In  preserving  the  sequentied  execution  model  as  implemented  by  (3,  20),  Architect 
now  has  two  execution  functions;  one  execution  function  simulates  non-event-driven 
sequential  processing  and  the  other  simulates  an  event-driven  model. 
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6.  New  functions  were  implemented  within  Architect  to  generate  SetState,  Update, 
TVansmit,  and  Remove  events. 

7.  The  semantic  checks  were  updated  to  determine  the  mode  of  execution  and  perform 
additional  checks  as  required. 

8.  The  import  and  export  areas  of  subordinate  subsystems  were  consolidated  to  the 
import  and  export  areas  of  the  highest-level  subsystem.  With  the  consolidation  of 
the  imports  and  exports,  the  information  of  an  import  or  export  object  was  exp<inded 
to  include  the  owning  subsystem  of  the  import  or  export  and  a  routing  scheme  to 
locate  the  primitive  that  produced  or  consumed  the  pjirticular  import  or  export. 

With  the  inclusion  of  events  into  Architect,  Architect  is  closer  to  allowing  the  sim¬ 
ulation  of  models  that  require  concurrent  behaviors.  This  allows  for  expansion  to  new 
domains  that  require  concurrency  to  more  realistically  represent  real  world  entities. 

8.3  Recommendations  for  Future  Research 

The  following  is  a  list  of  items  that  were  not  addressed  as  part  of  this  research  effort 
and  should  be  awidressed  in  future  research  efforts; 

1.  Further  validation  of  event-driven  capabilities.  The  event-driven  simulation  capa¬ 
bility  was  initially  demonstrated  using  the  event-driven  circuits  domain.  With  the 
expansion  of  Architect’s  technology  base  as  a  result  of  (27,  26),  these  domains  can 
be  transformed  into  event-driven  domains  to  further  validate  the  implementation  of 
events  within  Architect. 
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2.  Incorporation  of  a  “mixed-mode”  execution  capability  in  the  subsystems.  The  initial 
implementation  of  events  into  Architect  allows  only  one  mode  of  execution  for  a 
developed  application.  There  are  circumstances  where  we  want  some  independent 
subsystems  of  an  application  to  execute  in  a  non-event-driven  sequential  mode  while 
others  execute  in  an  event-driven  mode. 

3.  Concurrent  simulation.  The  event-driven  simulation  capability  within  Architect  al¬ 
lows  for  only  a  single  thread  of  control  within  an  application.  Expand  Architect 
to  include  cin  event-driven  concurrent  simulation  capability  with  multiple  threads  of 
control.  A  decision  will  have  to  be  made  as  to  what  level  of  nesting  will  be  allowed  for 
the  concurrent  processing  of  subsystems.  The  level  of  concurrency  must  determine 
whether  only  the  top  level  independent  subsystems  execute  concurrently,  or  whether 
subsystems  subordinate  to  the  top  level  subsystems  execute  concurrently. 

4.  Causality  dependency.  The  initial  event-driven  capability  incorporated  within  the 
definition  of  the  controller  of  a  subsystem  does  not  check  for  any  causality  dependen¬ 
cies,  The  subsystem  controller  should  be  modified  to  allow  for  the  specification  of 
causal  dependencies  on  the  order  of  events  that  must  occur  prior  to  the  execution  of 
the  subsystem.  These  causality  dependencies  prevent  the  execution  of  a  subsystem 
if  sdl  the  required  information  or  dependencies  between  independent  subsystems  axe 
not  met. 

5.  Modeling  of  real-time  systems.  Architect  does  not  employ  any  type  of  time  con¬ 
straints  in  the  execution  of  an  application.  Expand  Architect  to  include  the  modelling 
of  domains  that  incorporate  the  use  of  reail-time  constraints. 
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6.  Architectviral  transformation.  This  research  identified  components  of  alternative  ar¬ 
chitectures  along  with  the  associated  precondition  and  postcondition  for  their  state 
space.  Future  research  should  be  done  on  tr^lnsforming  an  architectural  compo¬ 
nent  and  having  Architect  employ  the  component  within  one  of  its  compositions. 
This  transformation  should  be  behavior-preserving  such  that  the  Architect  meets 
the  entity’s  preconditions,  and  after  execution,  Architect  satisfies  the  entity’s  post¬ 
conditions. 

7.  Meta-Model  for  architectures.  The  framework  developed  as  part  of  this  research 
identified  structural  components  common  to  all  five  of  the  software  zurchitectures 
analyzed.  Research  needs  to  be  continued  on  possibly  identifying  a  meta-model 
for  software  architectures.  The  meta-model  will  be  an  aid  in  the  transformation  of 
components  between  architectures. 

8.  Basis  for  am  architecture  metric  system.  Another  result  of  this  reseaurch  was  the  iden¬ 
tification  of  some  chairaicteristics  that  axe  necessairy  within  any  softwaire  airchitecture. 
The  two  characteristics  identified  were  the  encapsulation  of  state  amd  information, 
amd  the  limitation  of  the  scope  of  control  of  an  architecturail  entity.  Further  reseairch 
needs  to  be  done  on  identifying  metrics  for  evaluating  softwaire  architectures. 

8.^  Concluding  Remarks 

By  identifying  a  firaimework  for  amadyzing  software  architectures,  the  similairities  amd 
differences  aimong  architectures  were  identified.  With  these  qualities  evident,  a  better 
assessment  cam  be  made  as  to  whether  am  entity  or  component  from  amother  airchitecture 
or  domain  is  suitable  for  inclusion  within  a  system  or  domain  being  developed. 
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Architect  brings  software  engineering  a  step  closer  to  being  a  true  engineering  dis¬ 
cipline.  It  contains  a  public  technology  base  of  certified  components,  emd  it  provides  a 
means  to  verify  a  design  (through  behavior  modeling)  prior  to  full  scale  development.  It 
provides  the  capability  to  model  behaviors  of  objects  that  au-e  sequential  in  nature,  as  well 
as  being  able  to  model  the  relationships  between  independent  objects.  With  the  framework 
presented  in  this  thesis,  Architect  in  the  near  future  may  be  able  to  incorporate  models  and 
components  of  other  domains  and  architectures  directly;  thus,  Architect  may  provide  for 
the  reuse  of  designs  that  cross  domaiin  boundaries.  All  of  the  aforementioned  capabilities 
zure  needed  to  position  the  software  industry  to  attain  the  “megaprogramming”  environ¬ 
ment  needed  to  allow  software  systems  to  be  developed  on  time,  within  budget,  error-free 
and  most  importantly,  meeting  user’s  requirements. 


8-9 


Vita 


Warren  Evan  Gool  was  bom  on  April  8,  1961  in  Goldsboro,  North  Carolina.  He 
finished  his  secondary  schooling  at  Goldsboro  High  School,  graduating  in  1979.  Throughout 
his  schooling,  Warren  was  active  in  the  Boy  Scouts;  where  in  April  1978,  he  achieved 
scoutings  highest  award,  the  distinguished  Eagle  Scout. 

He  started  his  undergraduate  education  in  the  fall  of  1979  at  North  CaroUna  State 
University.  Also  while  attending  NCSU,  he  was  inducted  into  Phi  Eta  Sigma  Honorary 
Fraternity.  He  graduated  firom  NCSU  in  December  1983. 

Lt  Gool  came  on  active  duty  Febmary  15,  1984  when  he  reported  at  Tyndall  AFB, 
Florida.  He  was  assigned  as  a  software  systems  analyst  for  the  4702"'*  Computer  Services 
Squadron  (CPUSS),  a  multi-national  organization  responsible  for  developing  and  main¬ 
taining  the  software  for  the  Joint  Siuweillamce  System  (JSS).  While  assigned  to  the  4702"** 
CPUSS/RSSF,  he  developed  operating  system  software.  Diagnostic  system  softwjure,  and 
system  level  test  plsms  zmd  procedures. 

In  June  1988,  Captain  Gool  accepted  a  position  at  NORAD,  managing  the  software 
configuration  for  JSS.  He  organized  and  scheduled  the  agenda  for  the  Computer  Program 
Configiuration  Sub- Board  (CPCSB),  as  well  as  identified  situational  assessment  information 
requirements  for  NORAD’s  Air  Defense  Operations  Center. 

Captain  Gool  tremsferred  to  Wright-Patterson  AFB  in  May  1992  to  attend  AFIT  to 
complete  a  Masters  of  Science  (Computer  Systems). 

Permanent  address:  8175  Trafalger  Dr 

Colorauio  Springs,  CO  80920 


VITA-1 


Bibliography 


1.  Agrawala,  Ashok,  et  al.  “DSSA  for  Intelligent  Guidance,  Navigation  and  Control.” 
1992  IEEE  Symposium  on  Computer-Aided  Control  System  Design  (CACSD).  110- 
116.  IEEE  Control  Systems  Society,  1992. 

2.  Allen,  Rober  and  David  Garlan.  A  Formal  Approach  to  Software  Architectures.  Tech¬ 
nical  Report,  Carnegie  Mellon  University,  February  1992. 

3.  Anderson,  Cynthia  Griflin.  Creating  and  Manipulating  Formalized  Software  Archi¬ 
tectures  to  Support  a  Domain-Oriented  Application  Composition  System.  MS  thesis, 
AFIT/GCS/ENG/92D,  School  of  Engineering,  Air  Force  Institute  of  Technology (AU), 
Wright-Patterson  AFB,  OH,  December  1992. 

4.  Bailor,  Major  Paul  D.  “The  Big  Picture,  Software  Engineering  Becoming  More  Like 
Traditional  Engineering,”  CSCE793  -  Formal-Based  Methods  in  Software  Engineering 
(February  1993). 

5.  Bailor,  Paul  D.  and  others.  “Formalization  and  Visuadization  of  Domain-Specific 
Software  Architectures,”  AAAI-92  Workshop  on  Automated  Software  Design,  AAAI 
Conference,  6-11  (1992). 

6.  Batory,  Don  and  Sean  O’Malley.  “The  Design  and  Implementation  of  Hierarchical 
Software  Systems  with  Reusable  Components,”  (Januaury  1993). 

7.  Coad,  Peter  and  Edward  Yourdon.  Object-Oriented  Analysis  (Second  Edition).  En¬ 
glewood  Cliffs,  New  Jersey:  Pentice  Hall,  Inc,  1991. 

8.  Coglianese,  Lou,  et  al.  “DSSA:  Navigation,  Guidance,  and  Flight  Driector  Design  and 
Development.”  1992  IEEE  Symposium  on  Computer-Aided  Control  System  Design 
(CACSD).  102-109.  IEEE  Control  Systems  Society,  1992. 

9.  Cossentine,  Jay.  Developing  a  Sophisticated  User  Interface  to  Support 
Domain- Oriented  Application  Composition  and  Generation  Systems.  MS  thesis, 
AFIT/GCS/ENG/93D,  School  of  Engineering,  Air  Force  Institute  of  Technology  (AU), 
Wright-Patterson  AFB,  OH,  December  1993. 

10.  D’Ippolito,  Richard  S.  “Using  Models  in  Software  Engineering.”  Proceedings:  TRI- 
Ada  ’89.  256-265.  New  York,  NY:  Association  of  Computing  Machinery,  Inc.,  1989. 

11.  Dromey,  Geoff.  Program  Derivation,  The  Development  of  Programs  Prom  Specifica¬ 
tions.  Reading,  Massachusetts:  Addison- Wesley  Publishing  Company,  1991. 

12.  Fenton,  N  E.  Software  Metrics:  A  Rigorous  Approach.  Chapman  and  Hall  (Van 
Nostrand  Reinhold),  1991. 

13.  Fischer,  Charles  N  and  Rch2ird  J  LeBlanc.  Crafting  a  Compiler.  Menlo  Park,  Cali¬ 
fornia:  thebenj2unin/Cummings  Publishing  Company,  Inc,  1988. 

14.  Lee,  Kenneth  J.  and  others.  Model-Based  Software  Development  (Draft).  Technical 
Report  CMU/SEI-92-SR-00,  Software  Engineering  Institute,  December  1991. 

15.  Lipsett,  Roger,  et  eJ.  VHDL:  Hardware  Description  and  Design.  Norwell,  Meis- 
sachusetts:  Kluwer  Academic  Publishers,  1989. 


BIB-1 


16.  Lowry,  Michael  R.  “Software  Engineering  in  the  Twenty-first  Century.”  Automating 
Software  Design,  edited  by  Michael  R.  Lowry  eind  Robert  D.  McCartney.  627-654. 
Menlo  Park,  CA:  AAAI  Press/MIT  Press,  1991. 

17.  Luckham,  David  C.  and  James  Vera.  “^Rapide:  An  Executable  Architecture  Defini¬ 
tion  Language,”  (April  7  1993). 

18.  Mettala,  Lieutenant  Colonel  Erik  and  Marc  H.  Graham.  “The  DSSA  Program,” 
CrossTalk  -  The  Journal  of  Defense  Software  Engineering,  57:19-21  (October  1992). 

19.  Prieto-Diaz,  Ruben.  “Domain  Analysis  for  Reusability,”  IEEE  Computer,  63-69 
(March  1987). 

20.  Randour,  Captain  Mary  Anne.  Creating  and  Manipulating  a  Domain  Specific  Formal 
Object  Base.  MS  thesis,  AFIT/GCS/ENG/92D,  School  of  Engineering,  Air  Force 
Institute  of  Technology(AU),  Wright-Patterson  AFB,  OH,  December  1992. 

21.  Rich,  Elain  and  Devin  Knight.  Artificial  Intelligence,  Second  Edition.  New  York: 
McGraw-Hill,  Inc,  1991. 

22.  Rumbaugh,  James  and  others.  Object-Oriented  Modeling  and  Design.  Englewood 
Cliffs,  New  Jersey:  Pentice  Hall,  Inc,  1991. 

23.  Silberschatz,  Abraham  and  others.  Operating  System  Concepts,  Third  Edition.  Read¬ 
ing,  Massachusetts:  Addison- Wesley  Publishing  Company,  1991. 

24.  Vestal,  Steve.  A  Cursory  Overview  and  Comparison  of  Four  Architecture  Description 
Languages.  Technical  Report,  Honeywell  Systems  and  Research  Center  MN65-2100, 
February  1993. 

25.  Vestal,  Steve.  Software  Programmer’s  Manual  for  the  Honeywell  Aerospace  Compiled 
Kemal  (MetaH  Language  Reference  Manual)  (Draft).  Technical  Report  a.5,  Honey¬ 
well  Systems  and  Research  Center  MN65-2100,  Jime  1993. 

26.  Waggoner,  Robert.  Domain  Modeling  of  Time-Dependent  Systems.  MS  thesis, 
AFrr/GCS/ENG/93D,  School  of  Engineering,  Air  Force  Institute  of  Technology (AU), 
Wright-Patterson  AFB,  OH,  December  1993. 

27.  Warner,  Russel.  A  Method  for  Populating  the  Knowledge  Base  of  AFIT’s  Domain- 
Oriented  Application  Composition  System.  MS  thesis,  AFIT/GCS/ENG/93D,  School 
of  Engineering,  Air  Force  Institute  of  Technology  (AU),  Wright-Patterson  AFB,  OH, 
December  1993. 

28.  Weide,  Lieutenant  Timothy.  Developement  of  a  Visual  System  Interface 
to  Support  a  Domain- Oriented  Application  Composition  System.  MS  thesis, 
AFrr/GCS/ENG/93M,  School  of  Engineering,  Air  Force  Institute  of  Technol- 
ogy(AU),  Wright-Patterson  AFB,  OH,  March  1993. 

29.  Welgan,  Robert  L.  Domain  Analysis  and  Modeling  of  a  Model-Based  Software  Exec¬ 
utive.  MS  thesis,  AFrr/GCS/ENG/93D,  School  of  Engineering,  Air  Force  Institute 
of  Technology  (AU),  Wright-Patterson  AFB,  OH,  December  1993. 


BIB-2 


REPORT  DOCUMENTATION  PAGE 


form  Approved 
0MB  No  0704  0188 


^uoiic  r«oorT<<^C  OurQcn  tor  tni\  coti«aion  q1  mtorm^tion  ts  ostim^teo  to  1  t>Our  oer  r«%oonse.  including  lof  revtev^m^  mstruaionv  &e«rchmg  enstinQ  oau  hource^^ 

aatnermd  tne  matnuimng  th«  oata  rteooM.  and  comoteting  «no  reviewing  tne  collection  of  intormacion  Send  comments  reoarorng  this  Ourden  estimate  or  any  otne?  asoeci  ot  this 
colleaior  o*  information,  mciuoing  suggestions  tor  reducing  this  Ourcen  tc  Aasnmgton  «eaoQuarters  Services.  Oirer.orate  ’0'  information  ^seraiions  arm  Reoorts.  12 15  ietterson 
Oavis  Highway.  Suite  1204.  Arlington.  2A  22202-4302.  ar>o  tc  tne  QHice  of  Management  and  Budget.  Paperwork  Reourt.on  P^ciea  (0704*0 1B8).  Wasnmcton.  DC  20s63 


3  REPORT  TYPE  AND  OATES  COVERED 
Master  8  Thesis 


4.  TITLE  AND  SUBTITLE 

ALTERNATIVE  ARCHITECTURES  FOR 
DOMAIN-ORIENTED  APPLICATION  COMPOSITION 
AND  GENERATION  SYSTEMS 


6.  AUTHOR(S) 
Warren  E.  Gool 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  AOORESS(ES) 

Air  Force  Institute  of  Technology,  WPAFB  OH  45433-6583 


8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

AFIT/GCS/ENG/93D-11 


.  9.  SPONSORING /MONITORING  AGENCY  NAME(S)  AND  ADORESSIES) 
i  Capt  Rick  Painter 
!  2241  Avionics  Circle,  Suite  16 
j  WL/AAWA-1  BLD  620 
I  Wright-Patterson  AFB,  OH  45433-7765 


10.  SPONSORING /MONITORING 
AGENCY  REPORT  NUMBER 


Ui.  DISTRIBUTION /availability  STATEMENT 


Distribution  Unlimited 


12b.  DISTRIBUTION  CODE 


13.  AESTRAC^  IMaximum  200  words) 

This  thesis  presents  a  formalized  framework  for  comparing  the  structure  and  semantics  of  software  architectures. 
The  framework  uses  object  diagrams  for  analyzing  the  structure  of  the  architectures  and  the  euciomatic  approach 
for  analyzing  the  semantics.  This  framework  is  used  to  compue  the  Object  Connection  Update  (OCU)  model 
(developed  by  the  Software  Engineering  Institute)  against  four  other  software  architectures:  VHDL  defined  by 
Lipsett,  MetaH  defined  by  Honeywell,  ^iRapide  defined  by  Luckham,  and  hierarchical  software  systems  as  defined 
by  Batory.  The  goal  of  the  comparison  was  to  evaluate  the  OCU  model  for  suitability  within  prototype  application 
composition  and  generation  systems.  This  research  concluded  that  the  OCU  model  has  all  the  elements  necessary 
for  use  in  application  composition  and  generation  systems.  Additionally,  the  framework  identified  several  common 
elements  in  all  the  software  architectures.  These  common  elements  may  lead  to  the  development  of  a  “meta-model” 
for  softwaire  architectures. 


U.  SUBJECT  TERM 

Software  Engineering,  Automatic  Programming,  Systems  Engineering,  Computer 
Program  Verification,  Knowledge  Based  Systems,  Computer  Architecture 


17.  SECURITY  CLASSIFICATION 
OF  REPORT 

UNCLASSIFIED 


WSN  7540-0 :-280-550C 


15.  NUMBER  OF  PAGES 
XXX 


18.  security  CLASSIFICATION 

19.  SECURITY  CLASSIFICATION 

20.  LIMITATION  OF  abstract  = 

OF  THIS  PAGE 

OF  ABSTRAa 

t 

1 

UNCLASSIFIED 

UNCLASSIFIED 

UL 

Stanaarc  ^98  (Re. 

D.  -fJS  Stc 


